Controls / 7 min
Unknown is a state of its own. Treating it as failure can repeat a real-world action.
Proposed worksheet · Method notes updated 2026-11-11 · No independent effectiveness test
The decision
Reconcile the provider’s record before retrying an action whose outcome is uncertain.
Use this when
A tool may have sent a message, written a record or charged a payment before the connection failed.
Skip this when
The operation is read-only and can be safely repeated within its authorization. Still distinguish a missing result from a failed request.
Work through the checks
Name the operation before dispatch
Use the provider’s supported operation or idempotency key where available. Record the intended effect, destination, authorization and a reliable way to check status. Inventing a key that the provider ignores offers no protection.
Keep three outcome states
Confirmed completed, confirmed not completed and unknown require different next actions. A timeout means the response was not observed; it does not establish that the operation did not execute.
Inspect the authoritative record
Check the provider receipt or operation status through an authorized read. If completion is confirmed, recover the result without repeating the effect. If non-completion is established, recheck that the original permission still applies before retrying.
Rehearse with a local fake sink
Inject a crash before dispatch, after the fake sink commits and before the response, and after recording completion. Restart and inspect the operation ledger before retrying. Keep network and money out of the rehearsal.
What would count as success?
- Confirmed completed work is not replayed. Evidence for check 1
- Unknown work remains blocked for reconciliation. Evidence for check 2
- Every retry stays within current authorization and provider semantics. Evidence for check 3
Evidence to bring back
Proposed evidence plan, not observed results or extra mandatory process. Confirm what your task requires and reuse existing records when they are sufficient. Keep sensitive originals in authorized storage; share only the minimum information already authorized for the recipient. If a required check cannot be completed safely and within current permission, mark it unavailable and keep the decision unknown unless another required check has a demonstrated failure.
Confirmed completed work is not replayed.
Proposed evidence for acceptance check 1. No result has been observed here.
Bring back: Keep the operation identity, authoritative completion receipt and action trace showing that recovery retrieved the existing result rather than dispatching another effect. Minimize or redact recipient/payment details in any shared copy.
Not enough: A timeout, missing response or empty local log used as proof that the provider did nothing.
Unknown work remains blocked for reconciliation.
Proposed evidence for acceptance check 2. No result has been observed here.
Bring back: For an unresolved operation, record the attempted authorized status check, what it could not establish and the stop before retry. A later resolution must identify the same operation.
Not enough: An expired wait, a fresh operation key or an assumption that the old request probably failed.
Every retry stays within current authorization and provider semantics.
Proposed evidence for acceptance check 3. No result has been observed here.
Bring back: For any proposed retry, retain the evidence of non-completion, the provider’s applicable retry/idempotency behavior and the current approval scope. State any unresolved element before dispatch.
Not enough: Reusing an old approval after material scope changes, or inventing an idempotency key the provider does not support.
Stop or recover
If the effect cannot be reconciled, stop and report the exact uncertainty. Never use an alternate path simply to obtain a success response.
What this does not establish
A local rehearsal cannot prove exactly-once effects in an external service. Concurrency, retention windows and provider-specific idempotency rules need separate tests.
Reference links
These links leave the saved pack when selected. Check whether dated guidance still applies before relying on it.
- Stripe: idempotent requests (Online source)
Provider-specific idempotency semantics. Other providers and action types can behave differently.
Source review date: 2026-11-10
- AWS Builders’ Library: making retries safe (Online source)
Engineering background on retry-safe API design. Not proof of exactly-once effects for a particular external service.
Source review date: 2026-11-10
Keep your own evidence
The draft already identifies this method and its proposed requirements. Confirm those requirements against your task, then supply only the scope and observations you are authorized to record. No evidence or permission is prefilled. Reuse an existing suitable record if you have one.
- Open this guide’s Markdown draft
- Open this guide’s JSON draft
- Inspect the guide’s source hash and method identity
Your browser may show or download text files. Edit a separate working copy in your usual editor. This reader does not accept or save your answers.
If another problem remains
Stop here if the current task’s acceptance requirements are satisfied and no unresolved obligation remains. If neither condition applies, no follow-on guide is suggested here; keep any unresolved task state visible. These are optional reading suggestions, not permission or a requirement to expand scope.
Only if: The operation is reconciled and its result needs to survive the next handoff.
Make the handoff survive the sessionPreserve the exact receipt, output and any remaining limits in the approved store.
Only if: Within a delegated business workflow, nobody is clearly authorized to resolve the uncertainty or approve a materially changed action.
Draw the boundary before delegating the businessClarify the owner and scope before attempting another consequential step.