Retry an uncertain operation without duplicating work
Preserve request identity and inspect existing work before retrying an uncertain action.
Ouros editorial team
A timeout tells you that you did not receive a conclusive response. It does not tell you that no work happened. Before sending a second request, preserve the first request's identity and inspect the work that may already exist.
Put uncertainty in the right place
Imagine a request to create a report. The connection closes before the client receives a result. At least three explanations remain possible: the service never accepted the request, it accepted and is still working, or it finished but the response was lost. The same visible timeout fits all three.
Clicking again with a fresh identity can create a second report. Reusing an identity can help only when the particular service documents what that identity means, how long it is retained and which request details must match. There is no general “safe retry” rule for every action.
HTTP 202 is another useful distinction. As MDN explains, it means acceptance for processing, not successful completion. A received acceptance and a lost response are different observations, but both call for inspecting existing work rather than inventing a finished result.
Retain a private recovery record
Use this worksheet for your own record. It is not an API request schema or a service configuration:
service: SERVICE_NAME
operation_id: OPERATION_ID
idempotency_key: ORIGINAL_KEY
request_body_file: path/to/original-request.json
version: EXACT_VERSION_IF_APPLICABLE
last_observed_state: STATE
Keep the original key and original request together. If you change the body while reusing a key, the service may reject it or interpret it in a service-specific way. A recorded file path helps you find the original body; it does not upload that file or prove the service received it.
Operation and run identifiers can be sensitive in context. Store this record privately, omit tokens and avoid sharing raw authenticated requests. A support report usually needs the action, observed state and a safe identifier, not your credentials.
Decide from the saved state
If the existing operation is pending, keep watching that operation rather than starting another. If it is completed, inspect the result and any warnings. If it failed, read the saved error and look for partial effects before deciding to retry. If it is cancelled, do not assume every earlier effect was undone.
If you cannot find the operation, preserve the uncertainty. Check the service's documented lookup and retry behavior or ask support with a sanitized record. Do not turn “not found in this view” into “nothing happened” without knowing what the view covers.
For Loop Builder, keep loop version, invocation and run identities distinct. For an extraction, retain the extraction's own operation identity. Similar status words do not make the services' retry rules interchangeable. Zilch extraction remains paid separately, and a local worksheet does not change access.
The right recovery can be to wait, inspect, correct an input or make a separately reviewed new request. The goal is to resolve uncertainty while preserving work, not to promise that a repeated action will happen exactly once.