The Request Timed Out. Should You Send It Again?

An acknowledgement can be lost after work is done. AI-generated conceptual illustration; no real request or network test shown.

A create-task request leaves an application, the waiting indicator disappears, and no confirmation arrives. The tempting response is to send it again. But which problem would that solve: a task that was never created, a missing acknowledgement, or a result the caller has not yet found? Those possibilities need different decisions.

A missing answer leaves the outcome open

Imagine a fictional editorial workflow. A drafting tool asks a review tracker to create one review task for one brief. The tracker might save the task before its acknowledgement is lost. Alternatively, the request might never reach it. These are invented possibilities, not a report of a real integration or an executed network test.

The Amazon Builders’ Library explains this uncertainty through a resource-creation example: receiving no response does not establish whether creation happened. Repeating a non-idempotent operation may create an unwanted duplicate. Reconciliation seeks evidence of the original outcome before another creation is attempted.

For our fictional tracker, suppose the workflow records a request reference and the brief revision before sending. An authorized status lookup is part of the proposed contract. The reference identifies this logical request for a review task; a task with a similar title would not, by itself, establish that it belongs to the request.

The second row matters. In this illustration, a lookup might be inconclusive because its documented visibility window has not passed. The workflow would retain “outcome unknown” rather than relabel it “failed.” This is a hypothetical contract limitation to resolve during design, not a claim that every service uses delayed visibility.

Decide whether the error is eligible for retry

AWS’s retry-with-backoff guidance concerns transient faults such as temporary unavailability. It warns that frequent retries can increase contention and degrade service. Backoff spaces attempts out; exponential backoff increases the waiting interval. Waiting changes the timing, not the safety of repeating the underlying operation.

The same guidance distinguishes non-transient errors, where failing promptly is preferable to repeated calls. Retry eligibility therefore needs the actual operation’s documented error semantics, rather than a blanket rule that every unsuccessful request should be repeated.

In our proposed workflow, an invalid brief reference goes to correction, not a retry loop. Authentication, permission or security rejection stops the automated action. Changing the route, credentials or operation to get around that rejection is outside the proposal. A corrected or newly authorized operation would require its own explicit decision; the old timeout is not permission to proceed.

A bounded retry policy also sets an attempt limit and an overall time budget. Backoff adds to the caller’s wait, and the AWS pattern stops after unsuccessful attempts. Select limits using the real service contract and the workflow’s deadline; its illustrative settings are not universal defaults.

For the fictional review request, the unresolved deadline is “a reviewer still has time to act on this brief.” The design must turn that requirement into a concrete budget before implementation. This chapter supplies no retry count or delay schedule. When that budget is exhausted, the proposed branch ends with an unresolved case and a named responsible role, not a claim that no task exists.

Idempotency belongs to the operation’s contract

Idempotency means repeating the same logical request causes no additional intended side effects after its successful application. The Builders’ Library describes caller-provided request identifiers for expressing that intent. Identical payloads alone are insufficient: a caller might legitimately want two similar resources.

A service must define the identity’s scope, accepted parameters and retention. AWS’s idempotent API discussion explains that retention requirements vary. Reusing an identifier with changed parameters may be rejected under that service’s contract. Idempotency does not require byte-for-byte identical responses or promise universal exactly-once delivery.

In our example, “create a review for this brief revision” is the logical intent. Repeating that same intent would preserve its identity only if the tracker explicitly supports that behavior. Requesting a separate review is a new intent. Editing the brief revision while keeping the old identity would mix two requests and leave the intended outcome unclear.

Before relying on our proposed tracker, its designers must ask: where is the identity recognized, how long is it remembered, and how can the task be found? After retention expires, the design cannot assume the old identity still prevents duplicates. A reference stored only by the sender cannot supply a missing receiver contract.

Close the uncertainty before closing the case

Suppose the fictional lookup confirms the original review task. The workflow can continue using that task’s reference, even though the original acknowledgement never arrived. If the lookup remains inconclusive and no qualified safe retry is available, the proposed outcome is a handoff: request reference, brief revision, observed evidence and the unresolved question. Neither branch silently creates another review.

API, JSON and Webhooks: Follow One Event Between Two Applications explains the earlier boundaries between a readable message, a receipt and completed work. This chapter adds the next decision: establish what is known, check whether repetition is permitted and safe, and keep uncertainty visible when the evidence cannot close it.