The Edit That Was Overwritten By an Older One
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 |
|---|---|---|---|
| Mobile app | PUT accepted, 200, and the new address rendered back. | The change is saved. | ✕ wrong |
| Web session (still open on a laptop from the previous evening) | A stale form containing the old address; an autosave fired at 09:14:02 on a focus event. | Saving the user’s current form state. | ✕ wrong |
| Storage layer | Two writes to the same key with client-supplied timestamps 09:14:00.900 and 09:14:02.100. | The 09:14:02.100 write is newer; keep it. | ✕ wrong |
| Support engineer | An audit trail with the correct new address present and then gone. | A rollback or a bad deploy reverted it. | ✕ wrong |
4 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
The storage layer applied its rule perfectly and both writes were genuine user actions. Commit before reading on: was this a *concurrency* bug, a *clock* bug, or a *modelling* bug — and what evidence would distinguish them?
Write it down even if you are unsure. An unwritten guess quietly becomes “that is what I thought” the moment you read the answer.