After a submission times out, how do you prevent duplicate orders or approvals?
A timeout means the caller did not receive a result in time. Safe recovery needs a server-recognized request and a traceable outcome; investigate an uncertain request before treating another click as a new business action.
On this page5 sections
After a submission times out, establish the original request's outcome before deciding how to retry. Disabling the button is insufficient: a refresh, a new login or an integration's automatic retry can send the operation again. In a software delivery scope (Chinese), define request identity, server-side duplicate handling, result lookup and manual reconciliation. One business intention should remain traceable to its actual document.
Separate a retry from a genuinely new transaction
Suppose a user submits a purchasing request but the browser receives no response. Looking up or retrying that submission should retain its original request identity. Intentionally creating another application with identical contents is a different business intention. Do not merge operations solely because their fields match, and do not allocate a new identity every time the person presses the button.
The Amazon Builders’ Library discusses caller-provided request identifiers as a way to express that intent. For the project, also define the organization, operation type and target record associated with the identifier. This prevents accidental reuse across unrelated work. An identifier correlates operations; possessing it should not itself authorize someone to view the resulting document.
Give the user a state that supports a decision
We recommend distinguishing accepted, processing, completed, explicitly failed and outcome awaiting confirmation. A successful technical response only establishes what that interface agreed to accept or complete. It does not mean a submitted approval has been approved. Show a traceable request or document number and indicate whether the next action is viewing, waiting, correcting input or involving a designated owner.
| Available evidence | Suggested action | Do not assume |
|---|---|---|
| The request has an associated document | Show that document and its current state | Another document is needed |
| The server confirms ongoing processing | Continue checking the same request | The operation failed |
| The response was interrupted | Retain the identity and reconcile the result | Nothing was written |
| Non-execution is confirmed and the error is corrected | Follow the agreed retry or new-intent rule | Every failure permits the same retry |
HTTP Semantics does not support automatically retrying a non-idempotent request without a basis for doing so safely. An automatic retry feature therefore depends on the actual interface contract and tests. Increasing a front-end retry count alone does not provide the missing guarantee.
Specify the business boundary of duplicate handling
Retain the association between a request and its business document, and agree which result a duplicate should receive. If the same identifier is submitted with a different amount, target or approval action, detect the inconsistency rather than report the earlier operation as successful for the changed contents. If the original document was later cancelled, a delayed old request should not inadvertently create it again.
Specify retention for duplicate-handling records, lookup after expiry and responsibility for unresolved outcomes. Set the duration from actual retry and reconciliation needs; there is no universal period suitable for every system. Identify whether background work and writes to external systems are inside the same guarantee. One local order does not by itself prove that a connected application received only one effective action.
Interrupt the response, not only the incoming request
- After a normal submission, repeat the same request and confirm that it still refers to the same document.
- In a controlled test, interrupt the connection after the business write but before the response reaches the browser. Resume lookup and verify that no second document appears.
- Close and reopen the page. Confirm that the earlier request can be recovered instead of forcing a fresh creation.
- Submit different contents with the same identifier and inspect the explicit rejection or conflict.
- Repeat a downstream callback and verify that agreed side effects, such as approval progression or stock actions, do not occur twice.
Run fault injection in a test environment rather than casually interrupting production operations. Preserve the request identifier, document number, timing, final business state and connected-system results. Two request log entries may represent a legitimate retry. Two unintended business records are a different outcome, so counting log lines alone is not an acceptance test.
Assign recovery when the outcome remains uncertain
A long-unresolved request should appear in a work list with the responsible system, reviewer and next action. Do not turn that list into an unconditional bulk resend. Use the interface and data-ownership guide to decide which system provides the authoritative result. If the action starts from an exception dashboard, also inspect the exception-to-work-order return path. The person should see progress on the original work order instead of dispatching another merely to clear an unresolved message.