By Greg Nowak. Last updated 2026-11-14.
Your workflow reports a timeout, but the new job is already sitting in the operations system. Someone presses retry. Now there are two jobs, and the team has to work out which one to use and whether work has started against both.
n8n’s September 2026 guidance on API idempotency covers the problem behind this: a request can succeed even when its response never reaches the sender. Before an AI workflow repeats a write, it needs a way to recognise the original business operation. Otherwise, an ordinary recovery step can create more work for the people using the system.
Test what happens when the response disappears
Take a hypothetical workflow that reads an approved service request, uses AI to prepare a job description, then asks an operational system to create the job.
In a controlled test, let the destination create that job, then suppress the successful response before it reaches the workflow. The workflow sees a timeout. The job exists. What should happen when someone tries again?
Agree the answer before changing retry settings. Replaying the approved request should recover the existing job or stop for investigation if the outcome cannot be established safely. Check the destination records as part of that decision. A green execution indicator tells you too little about whether the team has one job or two.
Give each business operation an identity that survives a rerun
n8n distinguishes retries within one execution from manual retries and newly triggered executions. Its execution identifier changes across those later runs. Where duplicate protection needs to survive them, the guide recommends deriving an identifier from the input data.
For this example, that could be request-1042:create-job. Save it before sending the write, and reuse it for every attempt to carry out that same approved creation. Creating an invoice is a separate action and needs its own identity.
Keep the approved payload with the operation record, too. Asking AI to rewrite the description during a replay could produce different parameters for what is supposed to be the same request. Record the identity, intended action, approved payload and any confirmed destination reference together. If the business wants a change, handle that change explicitly rather than letting it slip into a retry.
| What you know | What happens next | Evidence to keep |
|---|---|---|
| The job was created | Return the existing job reference when the request is replayed. | Operation identity and destination job ID. |
| The request timed out after submission | Use the destination’s supported retry or lookup mechanism. If neither can resolve it safely, send it for review. | Original payload, key and submission time. |
| Another attempt is still active | Prevent a second local worker from submitting the same operation independently. | Current operation state and attempt reference. |
| The outcome is still uncertain | Assign recovery review before another creation attempt. | Attempt history, unresolved question and named owner. |
Close the gap between checking and writing
Two workers can both check for an operation, find nothing and proceed to create it. A lookup followed by a separate insert leaves that gap open.
The n8n guide describes database uniqueness constraints, conditional writes and locking as safeguards against concurrent duplicates. For this workflow, claim the operation through an atomic database action, then track whether it is active, confirmed or waiting for investigation.
That protects the local operation record. It does not, by itself, stop a remote system from creating another job after an ambiguous timeout. You still need the destination’s idempotency mechanism, a reliable way to reconcile the outcome, or a controlled stop for review.
Read the destination’s retry rules closely
Stripe’s idempotent-request documentation shows how much detail sits behind the phrase “supports idempotency”. For API v1, Stripe saves the status code and response body after endpoint execution begins. Repeat the request with the same key and you receive the saved result, including a stored 500 error.
API v1 also checks that repeated parameters match. Keys can be removed once they are at least 24 hours old; using a key after removal creates a new request. Validation failures and conflicts with an executing request do not save an idempotent result when endpoint execution has not started.
Those are Stripe API v1 rules. Other destinations need their own review. Document the supported mechanism, parameter requirements, retention window and retry conditions for each one. A request may sit in your recovery queue longer than the provider keeps its key. Before replaying it, check whether the protection still applies. Replacing a key just to get past an error can also remove the protection you were relying on.
Put the check in the code that writes
Claude’s tool-call documentation explains that the application executes client tools. The tool-use identifier connects a call with its returned result. Applications can return execution errors using is_error, and invalid requests or missing parameters can lead Claude to attempt a corrected call.
For the proposed workflow, the application’s write handler should check the business operation before submitting it. The model-facing call identifier links a tool call and its result; the durable operation identity tracks the approved business action across attempts. When the assistant asks to try again, the handler needs to consult that existing operation record.
The error message matters as well. If the destination’s outcome is unconfirmed, say so. Reporting that creation definitely failed gives the next attempt a false starting point. Prompt instructions can explain the retry policy, while application code enforces it.
Give someone a workable recovery queue
n8n’s error-handling documentation describes error workflows that begin with an Error Trigger. Error data can include the failed execution reference, the last executed node and a retry relationship. Execution IDs and URLs depend on the execution being saved, and trigger failures provide different information.
Those details help with diagnosis, but the proposed recovery queue also needs the business operation. Keep the original payload, destination, available response evidence and reason automated processing stopped. Assign an owner who can answer the question holding up recovery: does the destination already contain the intended job?
If the destination provides a reliable lookup by business reference, use it to establish what happened. If neither safe replay nor reliable lookup is available, someone needs to investigate before another creation attempt. The queue should make that decision possible without asking the owner to reconstruct the whole workflow.
Hand over a replay test the team can repeat
Run the suppressed-response scenario in an isolated test environment, then exercise the workflow’s actual recovery routes. Cover an automatic retry, a manual rerun and two concurrent attempts against the same approved request. Where key retention affects safety, also test the recovery policy for an operation outside that window.
Inspect the destination records and operation history after each test. You are looking for one intended job, a traceable reference and a recovery outcome the team can explain. Where the destination cannot support that result automatically, the test should show the workflow stopping in a controlled way.
A focused GrN engagement could cover the write operations, their business identities, database safeguards and each destination’s retry rules, along with ownership of recovery work. Greg could implement those changes and hand over the hardened workflow with a repeatable replay test. That gives the team evidence to review when the integration changes, alongside a clear process for handling the next uncertain result.
Related on GrN.dk
- Apache 2.4.68: What to Check Before You Call It Patched
- Your AI Workflow Runs on One Person’s API Key. Now What?
- Give an AI Agent Its First Job on a Simple Task Board
Need help with this kind of work?
Discuss your workflow’s retry and recovery design Get in touch with Greg.
