Safe retries need a durable operation identity

An idempotent method has the same intended server effect when repeated as when performed once under its defined semantics; it need not produce identical response bytes on every attempt. Deduplication gives an application a more specific operation-identity contract. Scope the identifier to the relevant tenant, caller authority, and operation type so unrelated users cannot accidentally share a result. The client must reuse the same identifier for retries of one intended action and choose a new one for a genuinely new action. Automatically generating a new key per retry defeats the purpose.

Bind the identifier to a stable request fingerprint covering the semantically relevant input. Reusing a key with a different amount, destination, or model parameter should produce a defined mismatch error rather than silently returning an unrelated result. Canonicalization must match the application's meaning; bytewise JSON equality can distinguish harmless formatting differences, while overaggressive normalization can collapse distinct requests. Authenticate and authorize every attempt, including result retrieval. A deduplication hit is not permission to reveal another principal's response, and an unpredictable key does not replace those checks.

A typical state model distinguishes an absent operation, an in-progress operation, and a completed operation with a stored result or retrieval reference. Concurrent attempts must not both observe absence and execute independently. Use a storage mechanism whose atomicity and durability cover the claimed invariant. If the effect and completed deduplication record are committed together in one transaction, a crash cannot expose one without the other under that transaction's guarantees. If the side effect occurs in an external system outside that boundary, a local record alone cannot provide the same guarantee; the external interaction needs its own compatible protocol.

Specify what a second attempt sees while the first is pending: it might wait within its remaining deadline, receive an in-progress response, or query a status resource. A worker timeout does not prove the worker stopped, so simply letting a second worker repeat the action after a lease expires can duplicate effects. Recovery must prevent stale execution from committing under the chosen mechanism. Store enough completion evidence for an ambiguous client to reconcile later. The transport's success or failure status is then one observation about an attempt, while durable operation state establishes the business outcome.

Retention must cover the retry and reconciliation horizon promised to clients. Once a completed key is forgotten, the same old request can look new unless another durable business invariant prevents replay. Time-to-live, manual cleanup, disaster recovery, and capacity eviction all affect that horizon. Make expiry behavior explicit: reject an expired operation identity when possible, require a new business decision, or state the narrower guarantee. Calling a cache a deduplication store does not make eviction harmless. Tests should include a crash after effect commit, concurrent retries, payload mismatch, lost responses, and replay just before and after the supported retention boundary.

The cache lab demonstrates the danger of finite remembered identities without implementing durable deduplication. For EACH run Reset, explicitly set BOTH capacity and stride, predict, then Play or Step. At t=0/N=16, (C,s)=(4,4) remembers a four-identity cycle and produces twelve hits; (3,4) produces none because every replay follows eviction. Edits retain t and recompute the trace from empty. These hits are only toy LRU membership: there is no atomic effect, persistence, fingerprint, tenant scope, or expiry clock. Explain which missing guarantees a real operation store must add before treating a remembered key as safe replay evidence.