Idempotent business commands
Resolve a command whose response was lost
Keep the original operation identity while establishing what happened. A new key can turn recovery into a second business action.
In this article
Find the original request record
Capture the account, command type and idempotency key from the client or workflow record. Confirm the material payload and the time of the first attempt.
Look up the server's state before advising the user to submit again. Completed, pending and uncertain requests need different responses. A client timeout does not establish that the server failed.
If the client lost its key, use the supported business lookup or reconciliation process. Do not infer identity solely from a similar payload when two identical operations could be legitimate.
Inspect the target effect
For a completed local operation, verify the recorded result and return it through the authorised status path. For an uncertain external call, use the downstream operation identifier or documented lookup.
A matching target value is useful evidence but may not prove which request caused it. Another user or process could have made the same change. Preserve that distinction when recording the resolution.
Do not delete the request record to force another attempt. That removes the identity protecting the caller from duplication.
Retry only within the known contract
If the operation is safe to replay with the same key, keep the original payload unchanged. Check the downstream retention window and error semantics before relying on its deduplication.
If the key has expired or the outcome cannot be established, use the defined manual or business recovery path. Creating a new key may be appropriate for a genuinely new action, but it should be a deliberate decision informed by the original effect.
Prevent multiple operators or workers from recovering the same uncertain request concurrently without coordination.
Communicate the established result
Tell the caller whether the action completed, remains pending or needs manual resolution. Use the recorded business outcome rather than an assumption based on the network error.
Keep a trace of reconciliation steps and any corrective operation. If the incident exposed missing client key persistence or an inadequate downstream status path, add a regression and repair that mechanism.
The goal is to restore a reliable result for the original intention. A successful second request with a new identifier is not necessarily recovery if it leaves two bookings, sends or mutations behind.
Primary sources
AWS Builders' Library: idempotent APIsStripe: idempotent requestsReferences checked 11 September 2026.