fix(live-suite): stop Firefox leaks, harden prune precondition, fix daemon-parity flake - #186
Merged
Merged
Conversation
…aemon-parity flake iter-146: three independent live-suite reliability defects found in a post-batch sweep after iter-142/iter-145 merged. - Theme A: live_96_profile_cleanup.rs's launch_headless() launched Firefox with a bare Command and no RAII guard, relying solely on `daemon stop` to reap it. Switched to LiveFirefox so its Drop is a reliable fallback on any failure or panic between launch and stop. - Theme B: live_profiles_prune_removes_all_when_no_firefox_running's precondition only checked `daemon status`, which stays blind to a directly-launched (non-daemon) Firefox. Replaced with an explicit scan of ff-rdp-profile-* owner-PID markers that names offending (dir, pid) pairs on violation. - Theme C: root-caused the iter-137 daemon-parity flake live — not a daemon restart. Two bugs in daemon/server.rs combined to strand target_count at 0/1 forever: a dropped catch-up event when no RdpTransport event sink was installed during the watchTargets handshake, and a placeholder about:blank target that gets destroyed microseconds after being subscribed to. Fixed with an early event sink (buffered + replayed in wire order) and a one-time WATCHER_SETTLE_DELAY before the first subscribe attempt. New live_146_suite_reliability.rs pins all three fixes. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
live_96_profile_cleanup.rs'slaunch_headless()launched Firefox via a bareCommandwith no RAII guard, relying entirely ondaemon stopsucceeding to reap the process. Switched toLiveFirefoxso itsDropis a reliable belt-and-suspenders fallback on any failure or panic between launch and stop — this was the root cause of the 4 orphaned Firefox instances found after a full sequential live sweep.live_profiles_prune_removes_all_when_no_firefox_running's precondition only checkeddaemon status, which stays blind to a directly-launched (non-daemon) Firefox — exactly the gap Theme A's leak exercised. Replaced withlive_owned_profile_dirs(), an explicit scan offf-rdp-profile-*owner-PID markers that names offending(dir, pid)pairs on violation instead of an opaqueleft: 1 / right: 0.uptime_secondsstayed continuous across a failing session). Two real bugs indaemon/server.rscombined to strandtarget_count/live_target_countat 0 or 1 forever: (1)establish_watcher's synchronouswatchTargetshandshake had noRdpTransportevent sink installed, so atarget-available-formcatch-up event racing ahead of its RPC reply was silently dropped — fixed with an earlympscsink installed before both the startup and background-retry handshakes, replayed into the real event channel in wire order; (2) a freshly-launched profile's placeholderabout:blanktarget gets torn down microseconds after being subscribed to, orphaning the watcher for the rest of the session — fixed with a one-timeWATCHER_SETTLE_DELAY(350ms) before the first subscribe attempt.live_146_suite_reliability.rspins all three fixes: zero-orphan-after-sequential-launches, teardown-survives-a-panic, and 5-consecutive-stable-daemon-parity-runs.Test plan
cargo fmt/cargo clippy --workspace --all-targets -- -D warnings/cargo test --workspace -qall greencargo run -p xtask -- check-iteration-ready --plan kb/iterations/iteration-146-live-suite-reliability.md --base origin/main— 11/11 PASSLive suite:
FF_RDP_LIVE_TESTS=1 cargo test -p ff-rdp-cli -- --include-ignored --test-threads=1— verify zerofirefox.*ff-rdp-profileprocesses and zero pinnedff-rdp-profile-*dirs remain after the run (dogfood_path in the iteration plan; requires a local Firefox binary, not run in this environment)## Claims vs code<generated 2026-08-12T11:29:57Z by ralph-loop>
WATCHER_SETTLE_DELAY→ ✅ matched in diff## Claims vs code<generated 2026-08-12T11:37:47Z by ralph-loop>
WATCHER_SETTLE_DELAY→ ✅ matched in diff