commands::compile::link::archive_cache::tests::preparation_safety_survives_fallback_and_cache_hit fails roughly half the time under the full parallel cargo test -p perry --bins run, and always passes in isolation. It is not attributable to any branch — I hit it while auditing #9070 and alternated main/PR twice to check:
| run |
1 |
2 |
| main |
FAILED |
FAILED |
| #9070 |
ok |
FAILED |
| main |
ok |
ok |
| #9070 |
FAILED |
ok |
2 of 4 on each side, and isolated it is green:
$ RUST_TEST_THREADS=1 cargo test -p perry --bins -- --exact \
commands::compile::link::archive_cache::tests::preparation_safety_survives_fallback_and_cache_hit
test result: ok. 1 passed; 0 failed; 1065 filtered out
The failure is the test's own precondition, not a behavioural assertion:
panicked at crates/perry/src/commands/compile/link/archive_cache.rs:438:13:
a valid cache hit must not prepare the archives again
That is the tell described in CLAUDE.md's perry-runtime note — a fixture precondition failing means another thread perturbed shared state, not that the code under test regressed. The difference is that this is perry, not perry-runtime, so it is not covered by the RUST_TEST_THREADS=1 pin that every CI path applies to the runtime crate; -p perry --bins runs on the default pool.
Two candidate mechanisms, not yet separated:
- the archive-cache tests share on-disk state under the target dir (a sibling test preparing or invalidating archives concurrently would make "a valid cache hit" stop being valid), or
- mtime granularity — a cache-validity check that compares timestamps can tie when two operations land in the same filesystem tick, which would explain why a faster run is likelier to fail.
Worth noting this is the same crate as the perry bin tests that mutate global PATH, so a per-test-isolated fixture directory (rather than a shared one) is the likely fix. Until then it is a real source of false reds on any PR that happens to touch this crate — I nearly attributed it to #9070.
commands::compile::link::archive_cache::tests::preparation_safety_survives_fallback_and_cache_hitfails roughly half the time under the full parallelcargo test -p perry --binsrun, and always passes in isolation. It is not attributable to any branch — I hit it while auditing #9070 and alternated main/PR twice to check:2 of 4 on each side, and isolated it is green:
The failure is the test's own precondition, not a behavioural assertion:
That is the tell described in CLAUDE.md's
perry-runtimenote — a fixture precondition failing means another thread perturbed shared state, not that the code under test regressed. The difference is that this isperry, notperry-runtime, so it is not covered by theRUST_TEST_THREADS=1pin that every CI path applies to the runtime crate;-p perry --binsruns on the default pool.Two candidate mechanisms, not yet separated:
Worth noting this is the same crate as the
perrybin tests that mutate globalPATH, so a per-test-isolated fixture directory (rather than a shared one) is the likely fix. Until then it is a real source of false reds on any PR that happens to touch this crate — I nearly attributed it to #9070.