One Bad Row Killed the Whole Batch: Partial-Failure Handling for n8n Loops

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

Один неверный элемент остановил всю пакетную обработку в n8n. Решение: изолировать ошибки на уровне элемента, собирать их в таблицу «dead‑letter» и детально отчётовать об обработанных, неудачных, пропущенных и повторно обработанных записях.

Задача

A single malformed record caused an entire nightly batch of lead processing to stop, leaving hundreds of good records unprocessed.

Результат

The batch loop now completes fully, failures are isolated and retried individually, and reporting distinguishes between processed, failed, skipped, and retried items.

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

• 1. Run per-item sub-workflow or error-handling branch to capture failures without throwing.
• 2. Return success or structured failure record to the main loop.
• 3. Collect failures into a dead-letter table with business key, error, and raw payload.
• 4. Report counts of processed, failed, skipped, and retried items.
• 5. Retry only items from the dead-letter list, applying dedupe checks.
• 6. Mark retried items as done or keep them on the list if they fail again.

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

A nightly workflow of mine processed a batch of new leads: enrich each one, score it, write it to the CRM. One night a single lead had a malformed phone field, the enrichment node threw, and the execution stopped.

Источник

First, isolate failures to the item that caused them. In n8n this means the per-item work runs where an error cannot kill the loop: a sub-workflow executed per item, or an error-handling branch that catches the failure and returns it as data instead of throwing.

Источник

Second, collect failures into a dead-letter list, not a log line. A failed item goes into a table with the item's business key, the error, and the raw payload — everything needed to reprocess it without re-running the whole batch.

Источник

Third, report four numbers, not one status. Processed, failed, skipped as duplicates, and retried.

Источник