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

Описание и применение

В n8n при таймауте повторного вызова провайдера отправка сообщения удваивается. Решение: создать устойчивый ключ, записать его в реестр, проверить наличие записи перед повторной отправкой и использовать ключ идемпотентности.

Задача

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

Результат

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

Рабочий процесс

• 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

Доказательства

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.

Источник

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

Источник

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

Источник