A sends a request to B and waits. Silence is compatible with a lost request, a slow B, a crashed B, a completed operation with a lost response, or a partition that blocks communication in one or both directions. A timeout means A’s waiting policy expired. It is not evidence that B performed no work.
Imagine two worlds that deliver exactly the same messages to A up to the timeout. In one, B crashed before doing anything. In the other, B completed the operation but its response is delayed. A has the same local evidence in both worlds. No local computation can reliably distinguish them at that moment. This indistinguishability argument will explain both safe retry rules and limits on consensus.
Separate the operation outcome from the waiting outcome
A request usually crosses several distinct boundaries before a client sees a result. The client prepares a message, a transport sends it, the server receives it, the server decides whether to execute it, and a response travels back. Some of these steps may happen despite the client's inability to observe them. A local send completing does not generally prove that the remote application executed the command. Even a transport acknowledgment need not say that application data reached durable storage. The interpretation depends on which component sent the acknowledgment and what that component promises.
Use a paper example involving an image-processing job. At local time zero, a client requests creation of job J. Its deadline expires after three seconds. In one execution the request never arrives, so no job exists. In another, the server durably creates J after one second, but the reply is lost. In a third, the request waits in a queue until the fourth second and then creates J after the client has stopped waiting. All three executions can produce the same visible client history through the deadline. A timeout cannot distinguish absent, completed, and still-pending remote work.
Cancellation adds another message rather than erasing these possibilities. Suppose the client sends Cancel J after timing out. That message can be delayed, lost, or processed after J finishes. A server may define cancellation as a conditional transition that succeeds only while the job is pending. A successful cancellation response then has meaning under that contract. Merely closing a connection or asking to cancel does not prove the server rolled back work. For irreversible actions, such as sending an email, a completed effect may have no literal inverse even if the application later records a cancellation.
The two-world reasoning in the opening section concerns knowledge, not equal likelihood. The lost-request world and lost-response world need not be equally common. A monitoring system may provide evidence that makes one more plausible. But if the correctness of an action requires knowing that no earlier effect occurred, a probability estimate does not supply that fact. A duplicate submission can be unsafe even when duplicate processing is rare. Choose a response to uncertainty that remains correct in every execution admitted by the contract, rather than silently assuming the most common execution occurred.
One possible status operation asks about J using its original identity. That helps only if the server defines how status relates to pending requests. A response saying unknown might mean no record currently exists, while an old delayed submission can still arrive later. Treating unknown as permission to create unrelated replacement work needs additional rules. The later retry lesson explains durable deduplication and identity retention. Here the necessary first step is to list the remote events that remain possible after each local observation, including events that may occur after the timeout.