perf(daemon): watch-set cache hit/miss telemetry#127
Conversation
Adds `AtomicU64` counters on `DaemonWatchSetCache` (hits / misses / stale_evictions / puts) that drive two observability surfaces: 1. **`tracing::debug!(target: "fbuild_daemon::watch_set_cache", …)`** on every `get` — one line per lookup tagged `outcome=hit|miss|stale` with key, age, and configured max_age. Filter-ready for anyone trying to diagnose a suspected stale-hit or cache-cold scenario without having to rebuild with a debug macro. 2. **`DaemonInfoResponse::watch_set_cache: WatchSetCacheStats`** on `/api/daemon/info` — aggregate snapshot of the counters plus the currently-configured window. A misconfigured `FBUILD_WATCH_SET_CACHE_SECS` (#122) is otherwise invisible at the CLI because a cache-miss looks identical to a pre-cache cold run. `stale_evictions` is reported separately from `misses` so operators can distinguish "window is too short" from "cache is cold / key is new" — the two failure modes warrant different responses and collapsing them throws away the signal. Counters are lock-free reads/writes on the fast path (single atomic fetch-add per get/put) so the observability cost is negligible. ## Tests - `stats_track_each_outcome` — table-driven scenario hits miss, put, hit, and stale-eviction, asserting each counter advances exactly once without bleeding into a sibling. - `stats_reports_configured_window` — round-trips `max_age_secs` through `with_max_age` so operators can confirm which window is actually in effect. All 128 `fbuild-daemon` lib tests pass; `cargo clippy --workspace --all-targets -- -D warnings` clean. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
|
Warning Rate limit exceeded
Your organization is not enrolled in usage-based pricing. Contact your admin to enable usage-based pricing to continue reviews beyond the rate limit, or try again in 48 minutes and 9 seconds. ⌛ How to resolve this issue?After the wait time has elapsed, a review can be triggered using the We recommend that you space out your commits to avoid hitting the rate limit. 🚦 How do rate limits work?CodeRabbit enforces hourly rate limits for each developer per organization. Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout. Please see our FAQ for further information. ℹ️ Review info⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (3)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Cuts a release containing the two P0 fixes landed since 2.1.19: - #134 "P0 regression — Operation not permitted (os error 1) on warm build" - #135 "preserve exec bit on fbuild console script in wheel" Both are currently blocking every FastLED uno build on GitHub Actions: the wheel's console script installs without +x, so CI can't even run `fbuild --version`, and the subsequent compile fails with `Operation not permitted (os error 1)` on every example. Also includes: - #131 rustfmt on lnk pipeline - #133 DiskCache leases.refcount schema migration - #128 AVR orchestrator fingerprint fast-path + telemetry (#127) - #126 FBUILD_WATCH_SET_CACHE_SECS env override - f8533d3 extend watch-set fingerprint fast-path to AVR orchestrator Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Cuts a release containing the two P0 fixes landed since 2.1.19: - #134 "P0 regression — Operation not permitted (os error 1) on warm build" - #135 "preserve exec bit on fbuild console script in wheel" Both are currently blocking every FastLED uno build on GitHub Actions: the wheel's console script installs without +x, so CI can't even run `fbuild --version`, and the subsequent compile fails with `Operation not permitted (os error 1)` on every example. Also includes: - #131 rustfmt on lnk pipeline - #133 DiskCache leases.refcount schema migration - #128 AVR orchestrator fingerprint fast-path + telemetry (#127) - #126 FBUILD_WATCH_SET_CACHE_SECS env override - f8533d3 extend watch-set fingerprint fast-path to AVR orchestrator Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Summary
Closes #123. Adds observability to
DaemonWatchSetCachevia two surfaces:tracing::debug!(target: \fbuild_daemon::watch_set_cache`, …)** — one line pergettaggedoutcome=hit|miss|stale`, with key, age, and configured max_age.DaemonInfoResponse::watch_set_cache: WatchSetCacheStatson/api/daemon/info— aggregate snapshot of hits / misses / stale_evictions / puts plus the currently-configured window.Why two distinct counters for `misses` vs `stale_evictions`
A pre-cache cold run looks identical to a misconfigured window at the CLI — you just see a slow warm build. Splitting the counters lets an operator tell "cache is too short" from "cache is cold / key is new" without scraping tracing logs.
Perf impact
Lock-free fast path: single
fetch_add(1, Relaxed)perget/put. Negligible.Tests
stats_track_each_outcome— end-to-end scenario over miss, put, hit, stale-eviction; asserts each counter advances in isolation.stats_reports_configured_window— round-tripsmax_age_secsthroughwith_max_age.128 daemon lib tests pass;
cargo clippy --workspace --all-targets -- -D warningsclean.Related: #120 (the cache), #122 (env override).
🤖 Generated with Claude Code