Bryan Helmkamp 4c4d4efcda fix(cli): detect zombies in server stop poll loop ... The `foreground_start_writes_tracing_to_storage_server_log` test consistently took ~10.4 s. 10.3 s of that was spent inside `fabro server stop`, which polls `process_running(pid)` every 100 ms until the server exits. The test's server is spawned as a child of the test process (`child.spawn()`), and the test only reaps it via `child.wait_with_output()` after `fabro server stop` returns. After Step A's revert, `process_running` is a plain `kill(pid, 0)`, which returns true for a zombie — so the poll saw the dead-but-unreaped server as alive and burned the full 10 s timeout. Add `fabro_proc::process_running_strict(pid)` — the same ps-shelling zombie-aware predicate commit 1ed8e6cbd introduced — and use it only in `fabro-cli`'s server stop poll. The hot paths that motivated Step A (test-harness marker scans, daemon-liveness probes) continue to use the cheap `process_running`. The ps cost (~2 ms per call) is paid at most once per 100 ms poll interval and only while the server process still exists. In a normal clean shutdown that's zero calls (process exits before the first poll). In the zombie scenario the loop exits after ~1 poll instead of running out the full timeout. Verified on this branch: cargo nextest run -p fabro-cli -E 'test(foreground_start_writes_tracing)' before: 10.48s, 10.45s, 10.42s after: 0.35s, 0.32s, 0.25s (30x faster) The zombie regression test removed in commit da87f978c returns as `process_running_strict_returns_false_for_unreaped_zombie_child`, and also asserts that the cheap `process_running` keeps its "zombie == alive" semantics so the harness hot paths stay honest. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>		2026-04-20 17:39:52 -04:00
..
crates	fix(cli): detect zombies in server stop poll loop	2026-04-20 17:39:52 -04:00
packages/fabro-api-client	Merge remote-tracking branch 'origin/main'	2026-04-20 09:47:47 -04:00