A client sends Transfer(10). The service commits it and crashes before replying. The client retries. Consensus can agree that both messages occupy log positions; that does not tell the application whether they represent one intended transfer or two. The client needs a stable operation identity that survives retry and service failover.
At-most-once processing can avoid duplicates but allow loss if work is abandoned after uncertainty. At-least-once delivery retries until sufficient confirmation under its progress assumptions, but can deliver duplicates. Claims of exactly-once effects need a specified boundary: which state change, which identities, which retained records, and which failures. They do not mean the network delivers a packet exactly once.
Retry identity belongs to the intended operation
A request has at least two identities worth separating. A transport attempt identifies one send, while an operation identity identifies the business action that several sends may represent. A new connection, server, or message number can change the attempt without changing the operation. If a client intends one transfer, its timeout retry must retain that transfer's operation identity. If it intends a second transfer of the same amount to the same recipient, that is new work and needs another identity. Comparing request bodies cannot reliably distinguish these intentions.
Use a separate paper case with an initial balance of 70. The client creates operation K to debit 12. The service commits the debit, leaving 58, but the success reply is lost. If the client retries as K, a correct deduplication protocol returns the original result and leaves 58. If it retries as J, the server has no basis for treating J as the same intended action and may debit again, leaving 46. Both requests can be correctly replicated. The error would be in the client's operation naming contract, not consensus on log order.
The client must retain K through the failures it expects to retry across. Generating a key only in memory does not help after a client crash if restart generates a different key for the same outstanding action. A client can durably record the intended operation before sending it, or use another documented recovery mechanism that retrieves its identity. Distinct clients also need noncolliding namespaces. A key scoped to one authenticated account may be valid, but the server must use that same scope when looking up results. The string K alone is not globally meaningful.
At-most-once and at-least-once describe different risks. Never retrying an uncertain action can avoid a second attempt while leaving a lost request unperformed. Retrying until confirmation can overcome temporary losses under eventual communication assumptions, but creates duplicates when confirmations disappear. Exactly-once business effects combine retrying with a receiver that recognizes repeated intent and applies one relevant mutation. The network may still deliver many messages. This guarantee must name its durable state boundary, key-retention period, and assumed failures rather than claim that uncertainty no longer exists.
A timeout should therefore leave a client state such as pending or outcome unknown, not silently convert it into confirmed failure. A definitive application rejection is different because it reports a known result for that operation. Even a status query can race with an in-flight request. If a query returns no record while the original request is still delayed, that request may arrive afterward. Treating absence as proof that sending new work is safe requires a cancellation, expiration, or ordering contract that actually prevents the old request from executing.