Summary
cargo test -p perry-runtime (full suite) is flaky on main, and CI runs cargo test --workspace, so it is a live source of red builds that get attributed to whichever PR happens to be in flight.
Evidence
Found while validating #7900/#7901/#7902 (gc-handoff/GCSAFE-NOTES.md):
- Two runs on a feature branch each failed one test — a different test each time.
- A pristine
b8c1f103e worktree then reproduced run 1's failure with a byte-identical message, confirming it is not branch-attributable.
Why this matters more than an ordinary flake
The failure lands on whoever is merging. Several GC PRs merged today with admin bypass; a flaky required suite makes it impossible to distinguish "my change broke this" from "this was already broken", which is exactly the condition under which a real regression gets waved through as "the usual flake".
CLAUDE.md's own framing applies: a gate that fails for reasons unrelated to the change is not a gate, it is noise that trains people to bypass it.
Suggested first step
Identify the flaky set and whether they share a cause (test-order dependence, a process-global GC counter, or shared thread-local state across cargo test's thread pool are the obvious candidates given the subject matter). Then either fix, serialise, or quarantine them explicitly — quarantine being far better than leaving them to fire at random.
Note perry-runtime tests share process-global collector state, and several GC tests use RAII thread-local overrides (OldDefragTestEnable, OLD_DEFRAG_TEST_OVERRIDE, barrier-arming overrides). Test-order or parallelism interaction there would produce exactly this signature.
Summary
cargo test -p perry-runtime(full suite) is flaky onmain, and CI runscargo test --workspace, so it is a live source of red builds that get attributed to whichever PR happens to be in flight.Evidence
Found while validating #7900/#7901/#7902 (
gc-handoff/GCSAFE-NOTES.md):b8c1f103eworktree then reproduced run 1's failure with a byte-identical message, confirming it is not branch-attributable.Why this matters more than an ordinary flake
The failure lands on whoever is merging. Several GC PRs merged today with admin bypass; a flaky required suite makes it impossible to distinguish "my change broke this" from "this was already broken", which is exactly the condition under which a real regression gets waved through as "the usual flake".
CLAUDE.md's own framing applies: a gate that fails for reasons unrelated to the change is not a gate, it is noise that trains people to bypass it.
Suggested first step
Identify the flaky set and whether they share a cause (test-order dependence, a process-global GC counter, or shared thread-local state across
cargo test's thread pool are the obvious candidates given the subject matter). Then either fix, serialise, or quarantine them explicitly — quarantine being far better than leaving them to fire at random.Note
perry-runtimetests share process-global collector state, and several GC tests use RAII thread-local overrides (OldDefragTestEnable,OLD_DEFRAG_TEST_OVERRIDE, barrier-arming overrides). Test-order or parallelism interaction there would produce exactly this signature.