n8n Reliability Lab

背景

当所有下游调用都成功时，Webhook 演示很容易。更有价值的问题是：遇到重复交付、可重试失败、等待审批、耗尽重试预算或人工重放后，系统还能保证什么。

这个 n8n 可靠性实验室是一个小型 localhost 系统：接收合成线索，在副作用前持久化状态，对特定事件进行人工审批，记录有界交付尝试，打开死信，并使用同一条交付路径安全恢复。

问题

n8n 执行内存无法单独安全协调重叠提交、进程重启和人工动作。因此，这个实验室让 PostgreSQL 成为事件身份、状态转换、审批决定、尝试、死信和重放所有权的台账。

交付保证被准确描述为 effectively-once，而不是 exactly-once。耐久事件 ID 会成为下游 Idempotency-Key，但外部服务接受请求后、尝试记录写入前仍可能发生崩溃。具备幂等能力的接收方可以合并重放；这个实验室不会假装崩溃窗口已经消失。

验收场景覆盖无效输入、重复提交、审批、瞬时 500 → 429 → 201、耗尽的 503 × 3 和受保护恢复。90 秒演示脚本已经覆盖重试和恢复序列，但公开录屏和已验证 Watch 链接尚未发布。n8n、PostgreSQL 与 WireMock 只在 localhost 运行，WireMock 是确定性故障夹具，不是真实 CRM。

这个案例证明什么

• 持久化和幂等边界比工作流节点数量更重要。
• 失败应该成为可查询状态，并带有有界恢复路径。
• 诚实的可靠性语言比不可能实现的跨系统保证更窄，也更可信。