skip to content

How does a per-run recipient address stop two concurrent runs of the same password-reset test from interfering?

level: seniorimportance: should knowfreq 38%

answer

  1. Two runs, one destination, one stream
  2. Which execution caused this email?
  3. A green run that never sent anything
  4. The assertion becomes total, not selective

basics

~20 s

A recipient minted for one execution makes the mailbox a partition of one: the only email there is the one this execution caused. Leftovers from earlier runs cannot satisfy the assertion, and concurrent runs cannot race for one single-use link.

solid answer

~50 s

A long-lived shared recipient guarantees three collisions: another execution's email can satisfy your assertion, both executions race to consume the same single-use link, and recipient-scoped delivery behaviour such as throttling or suppression is shared. Minting a recipient per execution removes all three at once, because nothing else in the world sends to that address. The assertion changes character with it -- it becomes *exactly one email arrived here*, a total check with no selection heuristic, which also catches duplicate sends for free. The worst case it prevents is not intermittent failure but a **false pass**: an execution that never sent an email at all can go green on a message a previous run left behind. What it does not isolate is the product's own records, or a cap keyed on the sending side rather than the recipient.

code

pseudocode · 12 lines
pseudocode
# one recipient per execution, so the assertion needs no selection
address = recipientFor(caseId, runId, attempt)

triggerPasswordReset(forAccountAt = address)

# total assertion: exactly one email may exist at this address
found = awaitMessagesAt(address, expected = 1, deadlineSeconds = 60)
assert found.count == 1                  # also catches a duplicate send
assert found[0].subject == "Reset your password"

# a concurrent execution derives a different address entirely and
# can neither observe nor consume this one

go deeper

for a junior

Recall the basic rule: an automated case should assert on an email it can prove it caused, which means sending to a recipient nothing else in the run uses.

for a middle

Explain the three collisions a long-lived shared recipient creates -- an ambiguous email, a raced single-use link, and shared recipient-scoped delivery state -- and how one recipient per execution removes each of them.

for a senior

Walk the false-pass sequence end to end and show why it is a correctness defect rather than flakiness, then state what address isolation still leaves shared and how you would cover that separately.

for a principal

Argue the isolation boundary as a strategy: which layer owns identity isolation, what it costs in routing and domain ownership, and where a team should stop buying isolation and start accepting a serialised suite instead.

## The interference a shared recipient guarantees When every case sends to one long-lived recipient, the emails of every case and every run land in one stream whose only structure is arrival order. Three consequences follow, and none of them is fixed by being more careful: - **Ambiguity.** An assertion that looks for *an email of this shape* can be satisfied by a message a different run caused. - **Consumption.** Single-use artefacts carried in the mail -- an activation link, a one-time code -- belong to whichever run reaches them first. - **Recipient-scoped state.** Throttling, suppression, unsubscribe status and *already sent this* logic in the delivery path are keyed on the recipient, so one run's behaviour changes the next run's delivery. ## The false pass, step by step This is the failure that makes a shared recipient a correctness problem rather than an annoyance: 1. Run A registers an account and triggers a confirmation email. The email arrives at the shared address. 2. Run A dies for an unrelated reason before consuming it. The message stays where it is. 3. Run B starts minutes later, registers, and looks for a confirmation email at the same address. 4. Run B finds run A's message, asserts on its shape, and passes. 5. The behaviour under test -- B's send -- never happened. The suite is green and the feature is broken. Intermittent failure is irritating. A **false pass is a lie**, and it is the reason this is a design question rather than a hygiene one. ## What the address boundary actually isolates Giving each execution its own recipient turns one contended, ordered stream into many streams of one. The assertion changes character: it becomes *the email at this address* rather than *an email in this stream that matches*, and a total assertion has no heuristic to tune. | Failure mode | Shared recipient | Per-execution recipient | |---|---|---| | Another run's email satisfies the assertion | Possible | Impossible, nothing else sends there | | A leftover message from an earlier run | Must be aged out or excluded | The mailbox starts empty | | Two runs consume one single-use link | Possible | Each execution has its own | | Recipient-scoped throttling and suppression | Shared | Per execution | | Adding parallel workers | Increases contention | Costs nothing | | Rerunning one case immediately | Not reliable | Safe | The last two rows are why this decides whether a notification suite can run in parallel at all. Isolation by address needs no lock, no queue and no coordination between workers: two executions that never name the same recipient cannot observe each other, so concurrency stops being a source of correlated failures. ## Getting the partition right - **Mint per execution, not per suite.** A single address created once in a shared setup reintroduces everything above; two cases in the same run that exercise the same notification will collide. - **Mint before the action.** The address has to exist before the request that triggers the send, or the case has nothing to assert against. - **Decide about retries deliberately.** Reusing the address on a second attempt means the first attempt's email is still sitting there and can satisfy the retry's assertion. A fresh address per attempt keeps every attempt's assertion total. - **Assert on count, not just shape.** *Exactly one email arrived here* is a stronger check than *an email arrived here*, and it is only available once the address is private -- it catches duplicate sends for free. - **Watch for caching helpers.** A convenience wrapper that remembers *the last recipient created* quietly restores sharing through the back door. ## What it does not isolate A private recipient is not a private environment. It leaves untouched: - **The product's own records.** Accounts, subscriptions and audit history still need their own per-run namespacing; that is a different concern with its own rules. - **Limits keyed on something other than the recipient.** A cap on outbound volume per sending identity, per source address or per hour is shared by every execution however many recipients you mint. - **Shared configuration.** A template edited mid-run, a feature flag flipped, a clock skewed for one scenario -- all still global. - **Products that canonicalise the address.** If the address you minted is reduced to a canonical form before the account is keyed, two distinct recipients can turn back into one account, and the partition you thought you had never existed. The honest summary is that address isolation removes an entire family of cross-run failures at almost no cost, and removes nothing else. Treat it as the first isolation boundary you reach for and the last one you should trust on its own.

  • Why is a leftover email from an earlier run worse than an intermittent failure?
    Because it produces a false pass rather than a red build. An execution that never triggered a send can find a previous execution's message, assert on its shape and go green, so a genuinely broken notification ships behind a passing suite. Intermittent failure wastes time; a false pass removes the signal the suite exists to give.
  • On a second attempt at the same case, do you reuse the recipient or mint a new one?
    Mint a new one, unless you deliberately want to observe both attempts. Reusing it leaves the first attempt's email sitting at the address, so the retry's assertion can be satisfied by the failed attempt rather than by the retry, which reintroduces exactly the false pass the per-execution recipient was meant to remove.
  • What cross-run interference survives even with a private recipient per execution?
    Anything not keyed on the recipient: the product's own account and subscription records, caps on outbound volume for the sending identity, shared configuration such as templates and feature flags, and a clock or environment one case mutates for everyone. Address isolation removes one large family of collisions and leaves the rest untouched.

A shared recipient is a communal pigeonhole: everyone's post arrives in one slot and you sort it out afterwards. A recipient per execution is a locker per delivery -- there is nothing to sort, and finding it empty is itself a result.

saying these in an interview costs you the question

  • Calls a false pass from a leftover email mere flakiness
  • Believes emptying a shared mailbox before each run makes it safe
  • Thinks a private recipient also isolates the product's account records
  • Reuses the same recipient across retries of one case
  • Assumes address isolation removes the need to wait for delivery
  • Says parallel runs are safe because each case uses different data