flakiness-concurrency

Race condition flakiness is fixed by serializing shared-state access so read-modify-write becomes atomic, using locks, queues, or await chains. First reproduce the race by running the test with high parallelism and repetition, such as vitest --repeat=200 --no-isolate, then verify the fix with consecutive green runs.

Test order dependency is detected by enabling vitest's --sequence.shuffle flag and running the suite with many different seeds. A test that passes alone but fails in the full suite, or vice versa, indicates state leakage between tests that must be fixed with beforeEach/afterEach isolation.

No, retrying flaky tests is explicitly discouraged because it hides nondeterminism and can mask real regressions. The correct approach is to quarantine the flaky test temporarily, identify its root cause, reproduce it with amplified variance, and contain it at the source.

Tests often fail only in CI because higher parallelism and machine load widen race windows that stay hidden locally. Reproduce the failure by increasing worker counts, adding machine load, and repeating the test hundreds of times to expose the timing-dependent behavior.

Model checking with TLA+ is appropriate when tests cannot cover all interleavings of a concurrent design, since tests only sample finitely many executions. Verify safety and liveness properties exhaustively with a model checker, then convert counterexample traces into regression tests.