Navigate this article
An order event arrives, a message is sent, and the connection drops before confirmation. Rerunning everything may send the message twice. Let's separate communication failure from action failure.
Define the input, effect, and owner
Before assembling nodes, describe the trigger event, required fields, and expected effect. Use a stable business-event identifier. A new n8n execution does not necessarily represent a new order.
Validate the payload and source credentials before calling external services. Use least-privilege credentials and a test destination for the exercises.
event: order_42_paid
action: notify_customer
key: order_42_paid:notify_customer
expected result: one confirmed notification
if ambiguous: reconcile before retryingA new attempt should not create a new action
Idempotency means repeating the same operation should not create unintended additional effects. If the provider accepts an idempotency key, reuse it for retries. Do not generate a different key on each execution.
Without provider support, record intent with a unique constraint and track its state. If the connection drops after sending, mark the outcome unknown and query or reconcile the destination. Recording ‘sent’ only before the call can lose a delivery; recording it only afterwards can duplicate one.
n8n orchestrates the workflow. Duplicate prevention also depends on storage and the destination system's behavior.
Choose which failures may be retried
Temporary unavailability may justify a bounded retry after a delay. Invalid credentials or rejected payloads usually need a correction. Retrying without distinguishing cases turns a small error into a queue of attempts.
Configure an Error Workflow to route failures to an owner. Include the execution identifier, failed step, and minimum investigation context. Keep personal data and secrets out of alerts. When a business rule prevents progress, Stop And Error can explicitly signal the failure.
- Define a retry budget and stopping condition.
- Do not ignore an error and report success to the user.
- Track pending, confirmed, failed, and unknown states where appropriate.
- Document who reconciles unconfirmed outcomes.
Test four situations before enabling the workflow
In a test environment, send a valid event and then repeat it. Next, simulate unavailability before the call and a lost response after the action. Check destination state, not just whether the execution turned green.
Finish when you can explain all four outcomes, identify the alert recipient, and reprocess without a duplicate effect. Keep these cases to repeat when the workflow or integration changes.
- Valid input: one confirmed action.
- Duplicate event: no additional effect.
- Failure before sending: bounded retry or handoff.
- Lost response: reconciliation before another action.
Do not use payments, bulk sends, or real customers to test these scenarios.
Sources and further reading
Educational material. Validate examples in a test environment and adapt decisions to your project's context, risks, and responsibilities.
Share