A logs request K to reserve seat 12 for Ada. B persists it and acknowledges; A commits and applies it. The reply to Ada is lost. A then becomes isolated from B and C. B, whose log includes K, wins the next term with C under the normal rules and establishes its current-term committed boundary. Ada retries K at B. B must return the saved result without reserving a second time. A stale search cache may still show the seat as empty, but an authoritative reservation by Bo must reject.
An old worker attached to A may still believe it owns an external resource. Fencing must be checked at that resource. A stale local read from A must not be presented as a linearizable confirmation. If B and C later cannot communicate with each other, lack of a majority can stop new decisions while the old committed seat assignment remains safe. No successful response is not the same as lost committed data. Conversely, forcing service by erasing history or bypassing quorum rules can create the loss you were trying to avoid.
Test competing explanations against the same observations
The incident above supplies a specified history with known premises. A real investigation usually begins with less information. Suppose a customer reports a timeout and later sees an empty seat in search. At least three explanations remain possible. The original request may never have reached the service. It may have committed while search still lags. Or the authoritative path may have violated its contract. These explanations require different evidence, so restarting everything before collecting records can destroy the distinctions needed to choose among them.
An operation-status lookup should use the original key and the documented authority, rather than issuing a new reservation as a diagnostic probe. If the status read itself is stale, an absent key does not settle the original outcome. If the API cannot distinguish absent from unknown during recovery, report that uncertainty. A new request identity creates new work and changes the system being investigated. Preserving the original identity lets the deduplication mechanism answer the original business question without deliberately introducing another effect.
Check the atomic boundary rather than merely searching for both records somewhere. A recovered seat owner and a recovered request result must represent the same committed transition if the retry contract depends on them. Two independently persisted records can appear correct after a clean shutdown while failing between writes. A snapshot that preserves the seat but omits a retained key can create the same problem after restoration. The relevant evidence includes transaction boundaries and snapshot metadata, not only the final business row. A durable deduplication result with different request parameters is also a contract error, not a valid retry match.
For guided exploration, construct two paper timelines that give the client the same timeout. In the first, stop before the server appends anything. In the second, stop after atomic application but before the reply arrives. Ask what a correct status protocol can eventually reveal after recovery. Then add an outbox event to the second timeline and let the relay crash after the receiver accepts it but before the relay records delivery. The business mutation remains single, while delivery may repeat. Receiver-side durable deduplication must protect any non-idempotent effect it promises to perform once.
These paper timelines are not additional controls in the worked model below. Its rows present the authored reservation incident and preserve all stages for comparison. They do not execute alternative leaders, snapshot installation, status queries, or an email service. Read the rows by asking which premise licenses the next conclusion. In particular, committed at A and B assumes the normal current-term commitment rules, and retry returns the result assumes replicated, recovered, atomic request-key state. Without those premises, the same row labels would not prove the claimed client behavior.