The Workflow That Sent It Twice: Reconciling Side Effects After a Retry in n8n

Description and use

In n8n, a timeout during a provider call caused duplicate notifications. The fix involves generating a stable reconciliation key, persisting a pending ledger entry, checking the ledger and provider before retrying, and using idempotency keys to ensure a single delivery.

Problem

A retry timeout caused a provider to accept a second identical notification, sending the same message twice to a customer.

Outcome

The workflow now guarantees a single notification per business event by reconciling side effects before retrying, preventing duplicate sends caused by provider timeouts.

Workflow

• Read row from sheet
• Build message
• Generate stable reconciliation key
• Write pending ledger entry
• Send notification with idempotency key
• If timeout, retry: check ledger for confirmed key
• If not confirmed, query provider by key
• If provider has record, mark ledger confirmed and skip send
• If provider has no record, send notification and record provider ID in ledger
• Assert provider count equals one after send or skip

Evidence

The workflow reads a row, builds a message, and calls the provider's send endpoint. The provider accepts the message, queues it, and then the connection stalls before the response comes back.

Source

A timeout lives in the gap between accepted and confirmed. Treating a timeout as failure is the mistake.

Source

Derive one stable key from the business event, not from the attempt.

Source