Two automated suites share one test recipient account and run at once — what breaks first?

## The mailbox is rarely what breaks A shared recipient looks like a shared mailbox, so that is where people expect the collision. In practice a mailbox is append-only and copes well with two writers. What breaks is the **identity behind it**: one account, one record, one set of fields that can hold only one value at a time. Two runs pointing at that identity are two writers to the same record, and neither of them knows the other exists. This matters because the failures do not look like contention. They look like delivery problems, and teams spend days on the sending path before anyone checks the clock. ## The failure ladder Ordered by how quickly each one bites and how badly it misleads: | What is shared | What the second run does to the first | How the failure presents | |---|---|---| | An outstanding single-use code or link | replaces it, because most products keep only the latest | "the code in the email is rejected as invalid" | | Sign-in credentials | invalidates a live sign-in when one run changes them | "signed out halfway through the case" | | Verification, subscription or consent flags | flips one off | "no email was sent at all" | | Locale, timezone or format preference | changes what the message template renders | "the assertion on the greeting text fails" | | Read or seen state in the mailbox | clears the basis of another run's filter | "the message was not found" | | Per-recipient send limits | consumes the budget with a burst | "the message never arrived" | Two things stand out in that table. First, only the last two rows involve the mailbox at all. Second, every symptom in the right-hand column points at the messaging path, and not one of them points at the actual cause. ## Containing it while keeping the account shared Sometimes the account has to stay shared: a corporate domain that cannot mint addresses on demand, a paid seat, an identity bound to a physical device, a product that treats one address as one customer. Containment then rests on four moves. 1. **Classify every case by whether it mutates the shared identity.** Reading an email, following a link, checking a rendered template — none of these contend. Changing a password, requesting a reset, toggling consent, changing the address — all of these do. Only the second group needs protection. 2. **Lease the identity for the mutating cases.** A worker acquires the account, holds it for the duration of the case, and releases it. Reads stay parallel; only mutation queues. A lease that expires also survives a worker dying mid-case, which a plain lock does not. 3. **Prefer additive work over mutation.** Where the product allows it, create a new sub-entity — an order, a subscription record, a document — instead of changing a field on the account itself. Additive work does not contend, so it never needs the lease. 4. **Never take a global action on the shared mailbox.** No clearing at setup, no marking everything read, no filtering on unread state. Those make your case deterministic by destroying someone else's evidence, and from the other run's side they are indistinguishable from a product bug. A small **pool** of shared identities, leased rather than one identity used by everybody, is usually the pragmatic shape. It holds concurrency at a level the product's per-recipient limits can absorb, it stops one long-held lease from serialising the whole suite, and it shrinks the blast radius when one identity ends up in a bad state. ## Making contention visible instead of arguing about flakiness Contention has a signature, and a suite can be built to show it rather than to hide it: - Failures **cluster inside the wall-clock overlap** between two runs and vanish when the runs are separated. - The failing case **passes every time in isolation** against the very same identity. - The failure text is about the message, but the last write to the account came from somewhere else entirely. Record, in every failure, which identity the case used and which run was holding it. That single line turns "the messaging tests are flaky" into "these two runs both held the same identity between 02:14 and 02:16". Without it the argument is unwinnable, because the decisive evidence lives in a run that nobody is looking at. One boundary is worth stating out loud. The general escape — giving each run a recipient of its own — is a different design with its own constraints, and it is not always available to you. Everything above is about the case where sharing is a given and the suite still has to be trustworthy.