fix(daemon): surface self-eviction blocker in logs (#51)#58
Conversation
Previously the self-eviction loop logged idle/busy transitions only at debug level, so users who saw `fbuild-daemon.exe` staying resident had no visibility into whether self-eviction was ticking or what was keeping it alive. Add `DaemonContext::busy_reason()` returning a human-readable blocker (operation in progress, N open serial sessions, N pending attaches) and promote idle-countdown + blocker messages to info level, with a 60s periodic reminder while a blocker persists. 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 25 minutes and 13 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 (2)
✨ 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 |
Summary
DaemonContext::busy_reason()returning a human-readable reason ("build/deploy operation in progress","N open serial sessions","N pending serial attaches") orNonewhen idle.debug!toinfo!so users see: (a) when the daemon goes idle and the countdown starts, (b) what's keeping it alive when it can't evict, with a 60s periodic reminder so stuck sessions are visible without tick-by-tick log spam.Context
Partially addresses #51: the reporter saw
fbuild-daemon.exestaying resident after autoresearch finished, but the existing self-eviction logic (empty for 120 s → shutdown) logs only atdebuglevel. That made the behavior invisible and indistinguishable from "eviction is broken." This PR surfaces the blocker atinfoso the next time someone hits this, the daemon log says exactly what's keeping it alive (e.g.,Daemon staying alive: 1 pending serial attach). The underlying eviction logic is unchanged.Test plan
uv run cargo clippy --workspace --all-targets -- -D warningscleanuv run cargo test -p fbuild-daemon --lib— 88 passed🤖 Generated with Claude Code