Skip to content

Sweep the directory it is given, not the one it looks up - #10

Merged
donislawdev merged 1 commit into
mainfrom
fix/sweep-test-isolation
Sep 8, 2026
Merged

Sweep the directory it is given, not the one it looks up#10
donislawdev merged 1 commit into
mainfrom
fix/sweep-test-isolation

Conversation

@donislawdev

Copy link
Copy Markdown
Owner

sweep_orphan_profiles called std::env::temp_dir() itself, so its test had no way to aim it anywhere but the shared %TEMP%. Two defects followed from that, and only the first one was known.

The flake. A dead driver's profile name has to carry a dead pid and can carry nothing else, so the fixture was the same name in every run. Two runs at once fought over that one name: 26 failures in 40 runs with a second process writing to it, against 0 in 20 sequential runs.

The one that was not on the list. A test run swept the real %TEMP%, so it deleted whatever chrono-cdp-* leftovers happened to be there. Measured: one run removed two unrelated directories it had never created. In the field those are a real session's leftovers, which a tester may still be reading - evidence, in a tool whose product is evidence.

What changed

The directory is a parameter now. Production passes std::env::temp_dir() on the line above unique_temp_dir(), so the pair stays visible at the call site, and the ownership logic is untouched - the stability audit marks it as the part not to touch.

The test builds a root of its own, deliberately not in the chrono-cdp-* shape so a real sweep running beside it leaves it alone, and asserts inside it under the existing TempDirGuard so a failing assertion still cleans up.

Verification

Each half of the sweep's decision was reverted in turn, on the full 187-test binary run:

Revert Result
spare nothing fails a live driver's profile must survive the sweep
remove nothing fails a dead driver's profile is what the sweep is for
same contention as before the fix 26 failures to 0
unrelated directories after a run survive, where they were deleted before

Gates 12/12, Rust 419, C# 365, probe harness 146 PASS / 0 FAIL.

Known and out of scope

cargo test still sweeps the real %TEMP% by another route: the flag-refusal test calls launch_chromium with an argument that passes validation and reaches the production sweep. Closing that needs the directory injected into the public launch_chromium signature, which has four call sites - a separate change.

🤖 Generated with Claude Code

The sweep called std::env::temp_dir() itself, so its test had no way to aim it
anywhere but the shared %TEMP%, and two things followed from that.

A dead driver's profile name has to carry a dead pid and can carry nothing else,
so the fixture was the same name in every run. Two runs at once fought over that
one name: 26 failures in 40 runs with a second process writing to it, against 0
in 20 sequential runs. That is the flake.

The other half is worse and was not on the list. A test run swept the real
%TEMP%, so it deleted whatever chrono-cdp-* leftovers happened to be sitting
there - measured, one run removed two unrelated directories it had never
created. In the field those are a real session's leftovers, which a tester may
still be reading.

The directory is a parameter now. Production passes std::env::temp_dir() on the
line above unique_temp_dir(), so the pair stays visible at the call site, and
the ownership logic is untouched. The test builds a root of its own, deliberately
not in the chrono-cdp-* shape, and asserts inside it under the existing
TempDirGuard so a failing assertion still cleans up.

Verified by reverting each half of the sweep's decision in turn, on the full
187-test binary run: sparing nothing fails "a live driver's profile must survive
the sweep", removing nothing fails "a dead driver's profile is what the sweep is
for". Gates 11/11, Rust 419, C# 365, harness 146 PASS.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@donislawdev
donislawdev merged commit 989a7b9 into main Sep 8, 2026
8 checks passed
@donislawdev
donislawdev deleted the fix/sweep-test-isolation branch September 8, 2026 18:58
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant