test(cli): pin daemon crash-recovery with a real-process regression test (#1228) - #1232
Conversation
…est (#1228) The #1228 trace on current main shows the residual respawn failure no longer reproduces: after an unclean daemon kill, the next client invocation detects the dead endpoint (via the #1227 owner-liveness gate), respawns a sibling fbuild-daemon on the same deterministic port, and the request succeeds (~5s observed). Pin that behavior end-to-end: spawn the real binaries, terminate the daemon hard, and assert the very next CLI invocation reaches a NEW daemon PID. Ignore-gated like the #1159 real-daemon test; skips rather than contending when a live dev daemon owns the real ~/.fbuild/dev root, since the production spawn path rebuilds the daemon env from the OS user baseline and cannot be HOME-isolated. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
Warning Review limit reached
Next review available in: 54 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: Path: .coderabbit.yaml Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
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 |
…erited from #1232) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
…break inherited from #1232) Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
The ban_std_pathbuf dylint denies new PathBuf usage and the allowlist forbids new entries; the #1232 test slipped in with four explicit mentions and broke the Dylint gate on this branch. Use NormalizedPath. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Closes #1228
Trace results (issue ask 1)
Reproduced the crash scenario empirically on current main (Windows, dev mode, real binaries): started a daemon, hard-killed its PID, ran the next client invocation with tracing.
The residual respawn failure no longer reproduces. The client logged
daemon not running, starting..., respawned a siblingfbuild-daemonon the same deterministic port, and the request succeeded ~5.4 s after the kill (old PID 34184 → new PID 38452, port 58866). The chain that fixed it since the 2.5.2 incident: the #1227 owner-liveness gate (stale records no longer masquerade as a live daemon), #830 sibling-binary spawn, #1010/#1159 spawn single-flight, and the #1208 wall-clock readiness budget.Fix (issue ask 2)
No code defect remains on the traced path — the deliverable is the regression pin (below). Two scoping notes recorded for follow-up rather than silently dropped:
ensure_daemon_runningtries running-process broker adoption before the direct path. If a stale broker lease ever hands out a dead endpoint, the client errors without falling back to direct spawn (daemon_client.rs:762propagates). The default mode is direct fallback, so this is theoretical until the broker ships enabled; the test pins the direct path explicitly viaRUNNING_PROCESS_DISABLE=1.user_baseline_environment), which discards any test/caller-providedHOME/USERPROFILE. This is why the test cannot HOME-isolate the daemon and instead skips when a live dev daemon owns the real root. It also implies a user with an overriddenHOMEgets CLI and daemon disagreeing on the fbuild root — worth a look if identity-derived-port mismatch reports ever show up.Regression test (issue ask 3)
crates/fbuild-cli/tests/daemon_crash_recovery.rs— real-process,#[ignore]-gated like the #1159 daemon test (runs underbash test --full/--include-ignored):fbuild daemon restartwithFBUILD_DAEMON_PORT=free port,FBUILD_CACHE_DIR=tempdir).terminate_pid), leaving stale records.Safety: skips (never contends) when a live dev daemon holds the real
~/.fbuild/devroot-owner lock, and when no siblingfbuild-daemonbinary exists.Validation
soldr cargo test -p fbuild-cli --test daemon_crash_recovery -- --include-ignored— 1 passed (16.7 s, real binaries, Windows).soldr cargo clippy -p fbuild-cli --tests -- -D warnings— clean.🤖 Generated with Claude Code