test(call_tool): make the auto-detach reproduction deterministic (fixes red main on macOS) - #1611
Merged
Conversation
`auto_detached_result` raced its own premise. It ran `sleep 0.1` against a 10 ms soft cap and assumed the child would still be running when the cap expired, so `run_foreground_or_detach` would take the detach branch. On a loaded macOS runner the helper can reach the cap check late enough that the child has already exited, `ForegroundResult::Finished` comes back, and the `let ... else` panics with "the reproduction must exercise the auto-detached path" — a red build that says nothing about the code under test. This is what turned main red on ea0e528 (run 33248005217, Test (macos-latest)), while the same commit was 29/29 green on its PR. The fix removes the timing assumption instead of widening it: the child now blocks on a barrier file (`LCTX_TEST_RELEASE_PATH`) until the test itself writes it, which is only after the detach has been observed. The child cannot finish early by construction, so the soft cap is guaranteed to fire first. `auto_detached_pipeline_result` already worked this way; this brings the plain helper in line with it. The four `let ... else` sites become a `match` whose `Finished` arm prints the exit code and the captured output. If detachment ever fails again for a real reason, the failure will say what the child actually did instead of only that it did not detach. No production code changes. Verification: cargo test --lib shell_outcome_tests (31 passed), cargo test --lib, cargo clippy --lib --all-features -D warnings clean, cargo fmt --check clean, scripts/loc-gate.sh OK. 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 subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Main went red on
ea0e5284bf(run 33248005217,Test (macos-latest)→CI Green) with:No production code is involved. The failing assertion is a test-harness race that predates the merged content — the same commit was 29/29 green on PR #1603.
What raced
auto_detached_resultdroverun_foreground_or_detachwith a 10 ms soft cap and asleep 0.1child, then asserted the result wasDetached. That holds only if the child is spawned, scheduled and still running when the cap check fires. On a loaded macOS runner it isn't always: the child completes first,ForegroundResult::Finishedcomes back, and thelet … elsepanics — with a message that says the premise broke and nothing about why.The fix
Remove the timing assumption rather than widen it. The child now blocks on a barrier file until the test writes it, which only happens after the detach has been observed:
It cannot finish inside the soft cap by construction, so the detach branch is guaranteed regardless of scheduling.
auto_detached_pipeline_resultalready worked exactly this way; this brings the plain helper in line with it instead of leaving two different reliability levels in one file.The four identical
let … elsesites become amatchwhoseFinishedarm prints the exit code and the captured output. If detachment ever fails for a real reason — a failed spawn, a missingsleepon some runner image — the failure will say what the child actually did.Verification
cargo test --lib shell_outcome_tests→ 31 passed, 0 failedcargo test --lib→ 10537 passed, 1 failed:tools::ctx_explore::tests::handle_output_is_byte_stable_across_runs, which passes in isolation and is unrelated to this file — a separate pre-existing flake, not something this PR introduces or claims to fixcargo clippy --lib --all-features -- -D warnings→ cleancargo fmt --check→ cleanscripts/loc-gate.sh→ OK🤖 Generated with Claude Code