[sentry-junior]

bigtable_rs logs failed background PingAndWarm requests at DEBUG. The default filter dropped them, so we could not see if warm pings also timed out during Bigtable incidents.

The default filter now enables DEBUG for bigtable_rs::bigtable. The Sentry layer sends these as Sentry logs. Stderr output stays at the configured level (info in prod). The filter targets the module and not the whole crate because bigtable_rs::auth_service logs at DEBUG on every request. The module also logs channel refresh start and end at DEBUG, about twice per pod every 50 minutes.

Ops does not set RUST_LOG for objectstore, so this applies in all regions.

via @lcian.

--

View Junior Session [Sentry]

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 91.91%. Comparing base (9a9c788) to head (43cdcd1).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@           Coverage Diff           @@
##             main     #734   +/-   ##
=======================================
  Coverage   91.91%   91.91%           
=======================================
  Files         117      117           
  Lines       24141    24141           
=======================================
  Hits        22188    22188           
  Misses       1953     1953           

Components	Coverage Δ
Rust Backend	94.92% <ø> (ø)
Rust Client	82.86% <ø> (ø)
Python Client	93.73% <ø> (ø)

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[sentry-junior]

At bigtable_rs 072cb58, bigtable_rs::bigtable=DEBUG adds only three debug! logs:

• Background PingAndWarm failed: {error}: the one we want. This happens at most once per channel per 10s warm tick, and only while pings are failing.
• Refreshing {n} channels / Refreshed {n} channels: about two per pod every 50 minutes.

Nothing else changes. The module's info! and warn! logs already pass the default filter. read_rows only uses trace!, which stays filtered. The per-request debug! logs in bigtable_rs::auth_service are excluded because the directive is scoped to the bigtable module.