全部教程

原创专题

n8n 错误工作流：失败发生后怎样定位

配置 Error Trigger 与主工作流关联，区分普通节点失败、触发器失败和缺失执行字段。

AI Nav City撰写 / 更新 资料核验

AI 工作流失败时，先保留可定位的执行信息，再决定是否重试。本文根据官方错误处理文档，说明建立 Error Handler 的步骤与字段边界；预期产物是一个能追踪失败来源的错误处理工作流。无需把消息发送到外部应用，先检查接收的数据是否足够。

操作与检查顺序

  1. 建立处理器

    新建以 Error Trigger 开头的工作流并保存。[1]

  2. 关联主流程

    在 Workflow Settings 的 Error workflow 中选择处理器。[1]

  3. 核对失败数据

    分别检查 workflow、execution 或 trigger 字段。[1]

每步分别核对输入、操作与结果，执行范围见末节。

把错误处理接到主工作流

  • 创建新工作流，首节点选 Error Trigger，取名 Error Handler，保存。
  • 回到主工作流，打开 Options → Settings，在 Error workflow 中选择 Error Handler，再保存。
  • 多个主工作流可以使用同一错误处理器；处理器应从收到的 workflow 字段识别来源。

[1]

官方说明关联后的错误工作流在主工作流执行失败时运行。保存配置只能证明关联被填写；实际是否触发、收到什么字段，还需要受控失败来确认。先让错误处理器保存或展示必要诊断字段，再考虑是否需要后续动作。[1]

不要假设 execution.id 总是存在

官方说明 execution.id 和 execution.url 依赖执行被保存；若失败发生在主流程触发器，主流程没有执行，这两个字段可能不存在。execution.retryOf 只在重试失败执行时存在。普通节点失败与触发器失败的数据形状不同，后者有更多 trigger 信息。处理器应检查字段存在性，不能直接拼一个可能不存在的执行链接。[1]

用受控失败核对诊断链路

原创练习：在一个可丢弃的主工作流中设置输入字段 valid。当 valid 为 false 时，按官方说明使用 Stop And Error 节点使执行失败。预期检查是 Error Handler 收到主工作流标识、错误信息和适用的执行字段。另准备触发阶段失败的情况，确认处理器能容忍 execution 字段缺失。不要用真实订单或真实外发消息作为练习输入。[1]

先定位，再决定重试

n8n 的 Executions 可查看失败记录并加载过去执行数据，官方也列出 Log streaming。对格式错误先修输入，对节点配置错误先修配置；是否可以重试取决于你的业务副作用与幂等设计。本文没有登录 n8n、创建工作流、触发失败、发送通知或执行重试；只核验官方步骤与字段说明，练习预期不代表真实运行结果。[1]

本文来源

本站原创整理；官方说明与编辑建议分别标注。

  1. n8n · 核验来源
    查看资料

文中工具

工具目录

n8n

通过节点和工作流连接外部服务、处理数据并加入 AI 步骤，用于业务流程自动化。