the flake was in the isolation, not the code

Two failures in the same period, and neither was a defect in the product. A totals assertion failed once in a run and passed on the retry. A later step in an unrelated scenario answered not-found for a row the test had just created. Both were blamed, briefly, on the code under test.

Both had the same root cause. Every test isolated its own data by wiping the shared store first, which is a reasonable instinct and, in a suite that runs concurrently, a write to state another test is midway through reading. The isolation was global and uncoordinated: the mechanism meant to keep tests apart was the thing colliding them.

The repair moved the guarantee rather than the symptom. One lock over the shared store, held across each test's entire body, with the wipe inside the held section, so seeding, acting and asserting became a single critical section nothing else could enter. A second defect of that family surfaced beside it: fixed account names seeded into a store that persists between runs, so the second run failed at setup for reasons unrelated to any change.

The proof standard matters as much as the fix. The claim was accepted only after consecutive fresh runs and a deliberately dirty re-run came back identical. A lock in a test is a hypothesis until it has been run twice over a store nobody cleaned.

Cost: the module now serialises, the suite takes longer, and parallelism that was never real was given up formally.

What it proves: the team treats a flaky test as a defect in the test's isolation, and will not close one on a single green run.