Prevent Duplicate AI Actions in n8n: IDs, Retries and Recovery

Short answer

Give each business action a stable ID and durable state before enabling retries; a timeout does not tell you whether the external action succeeded.

The implementation goal

This proposed design prevents an AI-assisted workflow from sending the same message or creating the same record twice during retries. It is a blueprint to adapt and test, not an imported workflow or a claim of production results. Begin with draft creation in a sandbox.

Step 1: define the business action

Use a source event ID and an explicit action version, such as order-847:draft-followup:v1. Do not use a fresh execution ID: a retry must resolve to the same business action. Keep model output outside the ID because repeated generations may differ. Decide which meaningful source changes require a new version.

Create a durable ledger with action_id, state, attempt_count, destination_id, last_error and updated_at. Enforce a unique action_id in storage. A spreadsheet lookup followed by an insert can race; two concurrent workers may both see no row. Use an atomic insert or transactional claim, with a lease and owner if work can outlive one execution.

Step 2: separate generation from delivery

Receive the event, claim the ledger row, generate a draft, validate it, obtain any required approval, then deliver. Save the approved payload before delivery. A retry should reuse that payload rather than silently create a different message. Define states such as received, prepared, approved, delivered, ambiguous and failed.

If the destination supports an idempotency key, send action_id using its documented mechanism. Confirm the key’s scope and retention. Your local ledger alone cannot guarantee exactly-once effects across a remote API. If the remote API has no such facility, prefer creating a draft or checking a unique external reference before a final action.

Step 3: classify failures

n8n’s error-workflow documentation explains assigning an Error Trigger workflow in settings and using Stop And Error for chosen failure conditions. Use alerts containing action ID, state and a sanitized error category. Never include customer message bodies or credentials in an alert by default.

Retry temporary transport errors with a bounded delay policy. Route invalid output and denied permission to a correction queue. If a request times out after delivery may have occurred, mark it ambiguous and reconcile the destination before resending. Cap attempts and assign a person to exhausted retries.

Step 4: run a failure drill

Submit the same event twice, including concurrently. Simulate a timeout after the destination accepts the request. Restart a worker after saving the prepared payload and before marking delivery. Try an expired claim and a revoked credential. Verify that each case leaves an understandable ledger record and no extra sandbox action.

Step 5: measure and release gradually

Track duplicate effects, unresolved ambiguous actions, retry cost and time to recovery. Count model tokens spent on retries as well as successful runs. Start with a small daily action ceiling and an operator stop control. Read our approval-gate guide and extraction validation guide before adding a write action.