n8n error handling: capture failures before adding retries
说明与用途
在 n8n 中实现单独的错误工作流,捕获失败、规范化数据并限制重试,从而降低重复操作的风险。
问题
An n8n workflow can fail mid‑run, leaving ambiguous state and risking duplicate side effects if retried immediately.
结果
Implementing a separate error workflow with normalized failure payloads and bounded retry logic reduces duplicate side effects and improves visibility of failures.
工作流
- 1. Separate main workflow from failure reporting by attaching a stable business key (e.g., order ID).
- 2. Create an independent error workflow with Error Trigger as first node and configure main workflow to point to it.
- 3. In the error workflow, capture execution reference and route an alert to an approved channel.
- 4. Normalize failure event payload using a Code node that outputs lean metadata (workflow name, executionId, failedNode, failureType, retryOf).
- 5. Give retries a stopping condition: store attempt counts with business key, set a tight attempt budget, and stop after budget exhaustion.
- 6. Reconcile remote state on ambiguous writes by querying external systems before resending.
- 7. Test failure path deliberately using sandboxed endpoints, fixture data, and Stop And Error node to simulate crashes; verify alerts and metadata.
- 8. Add a single bounded retry path for one transient failure mode after logging works reliably.
- 9. Test counter exhaustion and leave unknown failures visible until safe recovery is defined.
证据
An n8n workflow can fail mid‑run. It writes half its output, times out, and leaves behind an ambiguous state.
Make failures visible first. Then work out what is actually safe to retry.
Create an empty workflow with Error Trigger as its first node, then save it.
The Code node below generates a lean metadata payload. It deliberately leaves out raw input, error messages and stack traces, which can contain sensitive details.
Set a tight attempt budget for idempotent actions. Store attempt counts alongside the business key in persistent storage.
- 记录日期: 2026-10-16T20:41:35.137Z