Two Agents, One Ticket, Two Refunds
Read what each party saw, commit to a cause, and only then find out which of them was right. The root cause, why the obvious reading was wrong, and the fixes are all held back until you have answered.
The symptom
What was reported, before anyone knew what was happening.
What each party saw, and what each concluded
The evidence, in the form it actually arrived in — several parties, several partial views, several confident conclusions.
| Who | What they could actually see | What they concluded | Verdict |
|---|---|---|---|
| Agent A | A SELECT ... WHERE claimed_by IS NULL LIMIT 1 returning ticket 8841, then an UPDATE setting claimed_by = A that reported one row affected. | I have exclusively claimed this ticket. | ✕ wrong |
| Agent B | The identical sequence, 30ms later, also reporting one row affected. | I have exclusively claimed this ticket. | ✕ wrong |
| Database | Two unconditional updates to the same row, applied in order. | Both were valid writes. The second overwrote the first. | ✓ right |
| Operator | A claim table with one claimed_by per ticket and no conflict log. | The claiming works; the duplicate refunds must be a model reasoning error. | ✕ wrong |
3 of 4 parties reasoned correctly from what they could see and still reached the wrong conclusion. Nobody in this table is careless. Each one acted on complete-looking local information, and the information was local. That gap — between what a node can observe and what is true — is the whole domain, and one of these readings will usually be yours.
Commit before you read on
Both agents ran the same correct-looking claim sequence and the database applied both writes faithfully. Commit before reading on: identify the exact reason "one row affected" did not mean "I won", and say whether making the agents more careful could fix it.
Write it down even if you are unsure. An unwritten guess quietly becomes “that is what I thought” the moment you read the answer.