skip to content

A shared receiver has recorded many callbacks; how does a case prove which one its own trigger caused?

level: seniorimportance: should knowfreq 40%

answer

  1. Decide who owns the identifier
  2. Arrange it before the trigger
  3. Newest is not yours
  4. Select by key, assert exactly one
  5. The destination path can carry it too

basics

~20 s

Mint a value the case controls before triggering - a generated reference on the record it creates - and require that value to come back in the callback body or in the destination path. Select by that value, never by recency.

solid answer

~40 s

Correlation is arranged before the trigger, not deduced afterwards. Generate a value unique to the case - a reference on the record it creates, a distinctive name, or a per-case segment in the destination address - and carry it into the action so the system has no choice but to echo it. Then select the recorded request whose body or path carries that value, and assert that **exactly one** matched. If the payload only carries identifiers the system minted, capture the identifier from the trigger's own response and correlate on that instead. Selecting the newest recorded request is the failure hiding here: it passes when the case runs alone, breaks the moment anything else uses the same receiver, and can even match this case's own later callback for a subsequent state change.

code

pseudocode · 9 lines
pseudocode
order_ref = "case-" + unique_id()      # minted by the case, before the trigger
create_order(reference = order_ref, amount = 1200)

matches = receiver.requests_where(
    body.reference == order_ref and body.event == "order.settled")

assert matches.count == 1               # not "at least one", not "the newest"
assert matches[0].body.status == "SETTLED"
assert matches[0].body.amount == 1200

go deeper

for a junior

Understand that a receiver collects callbacks from everything pointed at it, so the request that happens to be there is not automatically yours. A case needs some identifier that lets it recognise its own.

for a middle

Explain how the key gets into the callback: generated in the case, passed into the action that creates the record, echoed by the system in the body it sends. Be able to say why selecting the newest request is wrong.

for a senior

Show the full predicate - key plus event type, with an exactly-one assertion - and the fallbacks when the payload carries no case-controlled value: the identifier from the trigger's response, or a per-case segment in the destination address.

for a principal

Own the contract angle. Whether callbacks echo a caller-supplied reference is a product decision, and winning that field turns an expensive correlation problem for every consumer into a lookup.

A receiver collects everything sent to it. Once more than one case, more than one record, or more than one state change is in play, "the callback that arrived" stops being a meaningful phrase - the store holds several, and only one of them is evidence of what this case did. **Correlation** is the step that turns a pile of received requests into a specific claim: *this* request was caused by *my* action. ## Recency is not correlation The convenient predicate is "take the most recent request". It is wrong in three separate ways, and each one produces a different flavour of failure: - Another case's callback can land between your trigger and your read, so you assert on a stranger's payload - and, because it is usually the same event shape, the assertions often pass. - Your own record can emit more than one callback. Created, then updated, then completed: the newest is the last state change, which may not be the one under test. - Delivery order is not causation order. Two callbacks sent close together can arrive in either order, so "newest" is a coin toss dressed as a selector. The tell is a case that is green in isolation and intermittently red in a full parallel run - and whose failure message says an assertion mismatched rather than that nothing arrived. ## Decide who owns the identifier, before the trigger Correlation works when the case controls a value that the system is forced to carry back. Which value depends on what the product offers: | Key source | How it gets there | Works when | Cost | | --- | --- | --- | --- | | A reference the case mints | Supplied on the action, echoed in the payload | The contract has a caller-supplied reference field | None; this is the good case | | An identifier the system mints | Captured from the trigger's own response, then matched | The create call returns the record it created | Requires the response to be usable | | A distinctive natural value | A generated name, an unusual amount, a unique address | The payload includes business fields | Fragile if the field is normalised or truncated | | A per-case segment in the destination | The case registers its own address before triggering | Destinations are configurable per subscription | Needs product support for per-subscription destinations | The first row is the one to lobby for. A callback contract that echoes a caller-supplied reference makes correlation a field lookup for every consumer of that product, not just for the suite. ## The predicate, not just the key A key alone is often under-specified. Write the selection as a real predicate and assert the cardinality it should produce: 1. Filter on the case-controlled key. 2. Add the discriminator the contract defines - the event type, the target state, the sequence field. 3. Assert **exactly one** match. Not "at least one": at-least-one silently accepts the world where your key matched two different events and you asserted the wrong one. 4. Assert on the matched request, never on the store. Step three is what makes the case notice that its assumption about the contract was wrong. If two callbacks legitimately match - created and completed for the same record - that is not a bug, it is a signal that the predicate needs the event type. If two match and the contract promises one, you have found something real. ## When nothing correlates Occasionally the payload carries no value the case can control or predict, and the destination cannot be set per case. Then correlation is genuinely impossible and the honest options are narrow: give the case an isolated data universe so that any callback about that data must be its own, take the identifier from the trigger's response, or record the gap as a testability defect and raise it with the team that owns the contract. What you do **not** do is fall back to recency and call it correlation - that converts a missing product capability into an intermittent failure the suite will pay for repeatedly. ## Keep the key readable in failures Because the key is the only thread from the case to the evidence, put it where a human will find it: in the case name, in the failure message, and in the reference field itself with a recognisable prefix such as `case-` plus a unique suffix. When a callback shows up in a log a week later, a key that says which case created it turns a mystery into a lookup. The same value serves double duty as the search term across the sender's records and the receiver's store. ## Failure modes - **Asserting on the newest recorded request** - the canonical version of this bug. - **Adding the key to the assertion but not to the trigger**, so nothing echoes it and every match is accidental. - **Correlating on a system-minted identifier the case never captured**, then asserting a value it guessed. - **Accepting at-least-one match**, which hides both an over-broad key and a duplicate contract violation. - **Reusing a fixed reference across runs**, so yesterday's retained callback satisfies today's predicate.

  • The callback body carries only identifiers the system generated. How do you correlate then?
    Take the identifier out of the trigger's own response - a create call almost always returns the record it made - and use that as the key. If the response returns nothing usable, read the identifier back through a query the case makes with a value it does control, and correlate on the result. Failing both, register a per-case destination so that routing does the correlating instead of the payload.
  • Your key matches two recorded callbacks instead of one. Is that a failure?
    It depends on the contract. One record often emits several callbacks for successive state changes, so two matches can be entirely correct and the predicate is simply under-specified: add the event type and assert exactly one per type. It is a genuine failure when the contract promises a single notification for that transition - and asserting exactly-one is the only reason the case noticed.
  • Why put the case's correlation key in the failure message as well as the predicate?
    Because the key is the only thread between the case and evidence scattered across the receiver's store and the sender's own records. A failure that names the key turns a week-old investigation into a search, and lets whoever picks it up confirm in seconds whether nothing was sent, something was sent about a different record, or the payload was wrong.

saying these in an interview costs you the question

  • Asserting on the most recently received callback
  • Assuming the receiver holds one request because the case triggered one action
  • Correlating on a value the system generated but the case never captured
  • Adding the correlation key to the assertion but not to the trigger
  • Passing when several recorded callbacks match the same key