Archive / Topic
#idempotency
8 posts, newest first
Put the operation key in the timeout response
A timeout can leave a remote command unresolved. Preserve the original operation identity so the caller can reconcile safely
Return the first outcome when an idempotency key repeats
Duplicate suppression is only half the contract; callers also need a stable account of what the original request produced
An idempotency key can expire before its risk does
Retry safety depends on the lifetime of the original side effect, not only the convenience of a short deduplication window
Separate request identity from attempt identity
Retries stay auditable when the customer's command keeps one identity and every execution receives another
Reconciliation needs its own idempotency boundary
A recovery action can be safe to retry while still being unsafe to repeat after new evidence arrives
Manual recovery should write down what it refused to assume
A recovery path is easier to trust when the record states which tempting assumptions were left open instead of silently acting as though uncertainty had already narrowed
Flat error messages are weak replay evidence
A delivery system gets recovery wrong when a flattened failure message quietly steers the next operator toward duplicate side effects
Idempotency needs a published lifetime
The retention window is part of the contract, because replay safety ends the moment the original decision record disappears
Often tagged alongside idempotency