An end-to-end suite runs eight workers in parallel against one shared staging environment. Giving each test its own freshly created records fixed most of the interference, but a handful of tests still fail only when the whole suite runs together. What kinds of state cannot be made unique per test, and what do you do about them?

## The category the record-per-test rule misses Generating fresh records fixes interference for anything the system can hold many of: users, orders, documents, projects. It does nothing for state the system has **exactly one of**, because there is nothing to make unique. Recognising which of your failures is in this category is most of the work — otherwise the symptom (fails only under load, passes when re-run alone) looks exactly like a timing problem and gets a wait added to it. ## The usual singletons - **Application-wide flags and settings.** A feature flag, a maintenance banner, a global tax rate, an admin toggle. One test flips it and every concurrent test is now running a different application. - **Constrained resources.** Limited stock, a seat count on a plan, a licence pool, a single "active" record where only one may exist at a time. Two tests both take the last one. - **Rate limits and quotas.** Eight workers hammering login or search from one IP hit a per-IP or per-account limit that never triggers when a developer runs one test. - **A shared mailbox or SMS endpoint.** Every test that verifies a signup email reads the same inbox and grabs someone else's message. - **Background jobs and schedulers.** A nightly digest or a queue worker processes everything in the environment, including records another test is mid-way through asserting on. - **Caches, search indexes and projections.** Shared, eventually consistent, and warmed by whatever ran last. - **The clock.** Anything that freezes or advances the environment's time affects every worker at once — this is why time manipulation belongs at a lower test level. - **Third-party sandboxes.** One sandbox account with one set of test cards and one webhook stream. ## Fix one: widen the isolation unit Before serialising anything, ask whether the "global" thing can be scoped. In a multi-tenant product, most settings are per-tenant, so giving each worker its own organisation converts a singleton into a duplicable record. Even in a single-tenant product, many settings turn out to be per-account or per-project. This is the highest-leverage move, because it keeps everything in the parallel lane. Concretely: allocate one organisation (and the data inside it) per worker at the start of the run, and let every test in that worker create inside it. For the mailbox, plus-addressing usually works: `[email protected]` routes to one mailbox but gives each test an address only it will match on, so tests never compete for the same message. ## Fix two: a serial lane for what is genuinely global Whatever remains — a truly application-wide flag, an environment-wide setting — gets an explicit serial group. The important part is that this is a **deliberate, named** arrangement, not an accident: those tests are tagged, they run in a lane that does not overlap the parallel lane, and the tag says why. A handful of serial tests costs a minute; the alternative is a suite nobody trusts. A lighter variant is a lock: a test acquires an exclusive lease on the flag, mutates, asserts and releases. That preserves parallelism for everything else, but it introduces its own failure mode — a crashed test holding a lease — so the lease needs a timeout. ## Fix three: move the scenario down a level Some of these scenarios do not belong in an end-to-end suite at all. Verifying that the UI renders differently when a feature flag is on is a component-level concern where you control the input directly and no shared world exists. Reserve the end-to-end version for the case where the flag's real propagation path is the thing under test — and then accept it is serial. ## Diagnosing which one you have The signature of singleton interference is: fails only when the full suite runs, passes in isolation, and the failure is a *wrong value* rather than a missing element — the page rendered fine, it just rendered someone else's world. When you see that, resist adding a wait; instead ask what the two tests both touched that only one of exists. ## Rate limits deserve a special note Parallel workers concentrate traffic from few addresses, so a limit sized for humans trips immediately. The right response is usually an environment-level allowance for the test identity rather than slowing the suite down — and if you disable the limit entirely in staging, remember you have also stopped testing it, so it needs coverage somewhere else.