An automated case asserts two deferred effects landed in a fixed order. When is that assertion illegitimate, and what replaces it?

middleshould knowfreq 45%

answer

Ask what the design promised
Two effects, separate paths
Another request's work interleaves
Assert membership before sequence

basics

~20 s

An ordered assertion is illegitimate whenever the design promises only that both effects happen, not the order they arrive in. Replace it with an unordered check: assert the set of effects, and assert sequence only where the contract states one.

solid answer

~50 s

Separate what the design guarantees from what your run observed. Two effects triggered by the same request usually carry no mutual ordering promise: they may be produced on independent paths, delivered by different routes, or interleaved with another request's work. An assertion that pins them in sequence claims something nobody signed up for, and it fails the first time those paths are rebalanced. The repair is to weaken the claim to what is promised, that both effects exist, that each carries the right content, that the counts are exact, and to keep sequence assertions only where the contract is explicit: an ordering promise scoped to a key, or a causal dependency where the second effect exists only because the first was handled. Where the ordering genuinely matters to a user, make it a product requirement first, then assert it.

Separate what the design **guarantees** from what your run **observed**. Two effects triggered by the same request usually carry no mutual ordering promise: they may be produced on independent paths, delivered by different routes, or interleaved with another request's work. An assertion that pins them in sequence claims something nobody signed up for, and it fails the first time those paths are rebalanced. The repair is to weaken the claim to what is promised, that both effects exist, that each carries the right content, that the counts are exact, and to keep sequence assertions only where the contract is explicit: an ordering promise scoped to a key, or a causal dependency where the second effect exists only because the first was handled. Where the ordering genuinely matters to a user, make it a product requirement first, then assert it.

code

pseudocode · 11 lines

pseudocode

effects = effects_for(orderId)

# over-claims: nothing promises which of the two lands first
assert effects == ["INVENTORY_RESERVED", "RECEIPT_WRITTEN"]

# claims only what the design promises
assert as_set(effects) == {"INVENTORY_RESERVED", "RECEIPT_WRITTEN"}
assert count_of(effects, "RECEIPT_WRITTEN") == 1

# sequence asserted only where the contract states the dependency
assert index_of(effects, "PAYMENT_CAPTURED") < index_of(effects, "RECEIPT_WRITTEN")

go deeper

for a junior

Be ready to say what your assertion actually claims. If you check that two results appeared in a particular order, know whether anything promised that order, or whether you copied it from the run in front of you.

for a middle

Explain the mechanics of over-claiming: independent paths, interleaving with other requests, and positional access into a collection of effects. Show how you rewrite an ordered check into a membership-and-count check without losing what the case proved.

for a senior

Demonstrate that you have removed these from a real suite: how you found them, how you argued that a failure under reordering is a defect in the case rather than the product, and what you left ordered because the contract genuinely says so.

for a principal

Own where ordering becomes a product requirement rather than a test convenience. Decide which flows must promise order for users, get that promise stated in the design, and keep every other case free to observe effects in any order.

What an ordered assertion actually claims

An assertion that effect A appears before effect B claims that the design forbids B from being observable first. That is a strong claim, and most deferred flows never make it. One accepted request commonly fans out to several independent paths, a reservation here, an outbound notification there, an audit record somewhere else. Those paths are scheduled separately, executed on separate units of parallelism, and finish in whatever order the moment allows. Nothing ties them to each other. The order your first run showed you is a fact about that run.

The reason an over-claiming assertion survives review is that it passes. It passes on the author's machine, it passes on the build server, and it keeps passing until some unrelated and entirely correct change flips the order: a path getting faster, a batch size changing, a step moving to a different pool. Then the case fails and points at the product, which did nothing wrong.

Where an unpromised order sneaks in

Positional access. Reading effects into a collection and asserting on the first element, or on position two, asserts an order without ever using the word.
Whole-collection equality. Comparing against a literal list makes order part of the claim even when the author only cared about membership.
Timestamp comparisons. Checking A then B in the body of a case is fine; asserting that A's recorded time precedes B's is an ordering claim.
Reading an append-only effect table in insertion order and asserting on what appears where.
Interleaving. Even where one request's own effects are ordered, another request's effects can land between them, so "the next effect after A is B" is a different and much weaker-founded claim.
A shared destination. Two effects arriving at the same place tells you nothing about which arrives first.

What replaces it

The rewrite is a weakening, and the discipline is to weaken exactly as far as the contract requires and no further:

What the case cared about	Over-claiming form	Honest form
Both effects happened	The collection equals `[A, B]`	The set of effects is `{A, B}`
No duplicates	The collection has length two	The count of each effect is exactly one
The content is right	Position one carries the right total	The effect named A carries the right total
A really does precede B	Position of A is below position of B	The same claim, but only where the contract states the promise

Notice what the honest forms keep. They still catch a missing effect, a duplicated effect, a wrong payload and a spurious extra one, which are the defects a case at this level exists to catch. Order was rarely doing any of that work.

The two exceptions that are real

Causal production. The second effect exists only because a handler processed the first. Then "no B without a preceding A" is enforced by the design and asserting it is asserting the contract. Note the shape: the well-founded claim is usually the implication, not the positions.
An explicit per-key promise. Where the design states that effects sharing a key are observed in the order they were produced, effects for that key may be asserted in order, for that key only. Widening it to effects across keys, or to effects produced on other paths, restores the original defect under a more respectable name.

In both cases write the scope into the assertion and into the case name. An assertion that says which key it covers is much harder for a later reader to widen by accident.

Finding the ones already in the suite

Three sweeps find nearly all of them:

Run the suite against a stand-in you control that deliberately varies arrival order and delays one path. Cases that fail under reordering are over-claiming cases, not product defects. This is the only method that finds the implicit ones.
Review for positional access into any collection of effects, since that is where an unpromised order usually hides unlabelled.
Read case names. A case called "effects are produced in order" should be able to cite the promise in one sentence; if nobody can, it is asserting a habit.

Making order a requirement instead of a habit

If a user genuinely depends on seeing one thing before another, a confirmation that must not arrive before the record it confirms, that is a product requirement and belongs in the design rather than smuggled into a case. Raise it, get it stated, then assert it as a promise somebody owns. A case is a poor place to store a requirement nobody has agreed to.

## What an ordered assertion actually claims An assertion that effect A appears before effect B claims that the design **forbids** B from being observable first. That is a strong claim, and most deferred flows never make it. One accepted request commonly fans out to several independent paths, a reservation here, an outbound notification there, an audit record somewhere else. Those paths are scheduled separately, executed on separate units of parallelism, and finish in whatever order the moment allows. Nothing ties them to each other. The order your first run showed you is a fact about that run. The reason an over-claiming assertion survives review is that it passes. It passes on the author's machine, it passes on the build server, and it keeps passing until some unrelated and entirely correct change flips the order: a path getting faster, a batch size changing, a step moving to a different pool. Then the case fails and points at the product, which did nothing wrong. ## Where an unpromised order sneaks in - **Positional access.** Reading effects into a collection and asserting on the first element, or on position two, asserts an order without ever using the word. - **Whole-collection equality.** Comparing against a literal list makes order part of the claim even when the author only cared about membership. - **Timestamp comparisons.** Checking A then B in the body of a case is fine; asserting that A's recorded time precedes B's is an ordering claim. - **Reading an append-only effect table** in insertion order and asserting on what appears where. - **Interleaving.** Even where one request's own effects are ordered, another request's effects can land between them, so "the next effect after A is B" is a different and much weaker-founded claim. - **A shared destination.** Two effects arriving at the same place tells you nothing about which arrives first. ## What replaces it The rewrite is a weakening, and the discipline is to weaken exactly as far as the contract requires and no further: | What the case cared about | Over-claiming form | Honest form | | --- | --- | --- | | Both effects happened | The collection equals `[A, B]` | The set of effects is `{A, B}` | | No duplicates | The collection has length two | The count of each effect is exactly one | | The content is right | Position one carries the right total | The effect named A carries the right total | | A really does precede B | Position of A is below position of B | The same claim, but only where the contract states the promise | Notice what the honest forms keep. They still catch a missing effect, a duplicated effect, a wrong payload and a spurious extra one, which are the defects a case at this level exists to catch. Order was rarely doing any of that work. ## The two exceptions that are real 1. **Causal production.** The second effect exists only because a handler processed the first. Then "no B without a preceding A" is enforced by the design and asserting it is asserting the contract. Note the shape: the well-founded claim is usually the implication, not the positions. 2. **An explicit per-key promise.** Where the design states that effects sharing a key are observed in the order they were produced, effects for that key may be asserted in order, for that key only. Widening it to effects across keys, or to effects produced on other paths, restores the original defect under a more respectable name. In both cases write the scope into the assertion and into the case name. An assertion that says which key it covers is much harder for a later reader to widen by accident. ## Finding the ones already in the suite Three sweeps find nearly all of them: - Run the suite against a stand-in you control that deliberately varies arrival order and delays one path. Cases that fail under reordering are over-claiming cases, not product defects. This is the only method that finds the implicit ones. - Review for positional access into any collection of effects, since that is where an unpromised order usually hides unlabelled. - Read case names. A case called "effects are produced in order" should be able to cite the promise in one sentence; if nobody can, it is asserting a habit. ## Making order a requirement instead of a habit If a user genuinely depends on seeing one thing before another, a confirmation that must not arrive before the record it confirms, that is a product requirement and belongs in the design rather than smuggled into a case. Raise it, get it stated, then assert it as a promise somebody owns. A case is a poor place to store a requirement nobody has agreed to.

The design does promise ordering for two effects that share a key. What does the case assert then?
Assert the sequence for that key only, and only among the effects the promise covers. Keep the assertion scoped: effects for other keys, and effects produced on a different path, stay unordered in the same case. Naming the key inside the assertion is what stops a later reader widening it into a global ordering claim the design never made.
How do you find existing cases that quietly depend on an order nobody promised?
Run them against a stand-in you control that deliberately varies arrival order and delays one path, and see which fail. A failure under reordering is an over-claiming case, not a product defect. Reviewing assertions for positional access into a collection of effects finds most of the rest, because that is where an unpromised order usually hides without being named.

saying these in an interview costs you the question

Asserts a sequence because that is the order the first run produced
Treats a collection of effects as ordered because it is indexable
Widens an ordering promise scoped to one key into a global one
Sorts the effects to hide the failure without asking what is promised
Assumes two independent paths interleave the same way every run

An automated case asserts two deferred effects landed in a fixed order. When is that assertion illegitimate, and what replaces it?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

What an ordered assertion actually claims

Where an unpromised order sneaks in

What replaces it

The two exceptions that are real

Finding the ones already in the suite

Making order a requirement instead of a habit

▾common follow-ups2 questions

▾red flags5 flags

What an ordered assertion actually claims

Where an unpromised order sneaks in

What replaces it

The two exceptions that are real

Finding the ones already in the suite

Making order a requirement instead of a habit

answer

go deeper