Prepared, and Waiting Forever
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.
PREPARED. The coordinator process was not running.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 |
|---|---|---|---|
| Participant DB-1 | A PREPARE it voted yes to, then silence. | I must hold my locks and my ability to commit or abort until the coordinator tells me which. I may not decide unilaterally. | ✓ right |
| Participant DB-2 | The same. | The same. | ✓ right |
| Orchestration platform | The coordinator pod OOM-killed and rescheduled onto a new node with an empty local disk. | Self-healing worked; the service is back. | ✕ wrong |
| On-call engineer | Two databases with blocked queries and no error anywhere. | A deadlock inside one of the databases. | ✕ wrong |
2 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 participants are behaving exactly as the protocol requires, and refusing to guess is the *correct* action for each of them. Commit before reading on: say what the coordinator lost when it was rescheduled, and why "just abort after a timeout" is not available to the participants.
Write it down even if you are unsure. An unwritten guess quietly becomes “that is what I thought” the moment you read the answer.