Aviral GargThe request to create a support ticket times out. The ticket may exist; the client has no reply. A second request could recover the interruption or create a duplicate. The next action depends on what the service can prove.
Before sending, the assistant records an operation ID and the intended ticket fields. That record becomes the link between the request it made and the result it needs to recover.
Two histories produce the same timeout: the service never accepted the request, or it created the ticket and the reply was lost. The client cannot distinguish them from its exception alone. Retrying with a fresh operation ID handles the first history but duplicates work in the second.
AWS’s explanation of idempotent APIs describes this ambiguity when a resource-creation response is lost. Its approach uses a caller-provided request identifier so the service can recognize repeated requests for the same intent. The service’s handling of that identifier is the important guarantee.
Keep one identity for one intent
Use a supported read-only lookup for the original operation or ticket, where the service offers one.
| Evidence | Action |
|---|---|
| Creation confirmed under the original identity; fields match | Use the existing ticket. |
| A documented retry contract covers this operation, key, parameters and retention window | Retry under that same contract and identity. |
| Outcome unresolved; no applicable retry contract | Keep the operation unknown and reconcile. |
A lookup returning nothing may be incomplete or delayed. Its absence is useful only to the extent the documented lookup guarantees it. If the API offers neither a reliable lookup nor a suitable retry contract, preserve the unknown state for resolution instead of inventing a successful recovery.
Read the actual contract
Stripe’s API documentation illustrates the specificity required. For API v1, retries with the same key return the first saved response, including errors. Parameters must match. Keys can be pruned after at least 24 hours; reusing a pruned key creates a new request. Results are saved after endpoint execution begins.
Retry guarantees depend on the API version, operation, error and retention window. Check the contract for the call you are retrying.
Reconciliation can also fail. A ticket with the same title is not enough: two legitimate requests may have identical text. Bind the result to the original operation ID, or another documented identity, and check its fields. If the result differs, preserve the discrepancy instead of quietly adopting it or submitting again.
A local log improves auditability, but cannot make a remote ticket creation and a local success record atomic. The server could create the ticket just before the client crashes. Recovery still needs the external service’s evidence or contract.
Track the request as prepared, submitted, confirmed successful, confirmed failed or unknown. Evidence determines the outcome; the API contract separately determines retry safety. A documented failure can still leave a partial effect, so check what it guarantees.
Keep one record of the intent, request identity and observed outcome. A timeout tells you the reply is missing. The service’s evidence and retry contract tell you what to do next.