RaydoRaydo Book

workflow 常见报错总表

统一看 workflow 里最常见的失败、停住和误判。

这一页不讲“理想搭法”,只讲用户最常遇到的报错和异常感受。

先说结论,workflow 出问题时,通常不是一类问题,而是下面四层里的某一层:

  • 输入层,入口字段、文件、数据、目标对象没准备好;
  • 节点层,节点配置、引用、数据形状或能力本身有问题;
  • 审批层,流程其实没坏,只是在等人决定;
  • 外部执行层,浏览器、连接、 Provider 或目标系统没真正执行成功。

最常见异常总表

你看到的现象更像哪一层常见原因第一反应应该做什么
一开始就跑不起来输入层必填输入没填、文件没选、目标对象为空回到入口表单,先补齐输入
某个节点直接失败节点层route 选错、输入映射错、上游没产出找第一个失败节点,不要只看最后一句话
节点没报错,但输出是空的节点层输入过宽、引用路径错、结果没被结构化先看输入映射,再看输出 schema
明明没报错,但流程不继续审批层正在等审批或角色未选定先去看审批,不要先怀疑系统坏了
审批通过后还是失败外部执行层目标系统拒绝、浏览器状态变了、连接不可用去看 run 详情和目标系统真实状态
提交后不确定到底有没有成功外部执行层browser submit 后无可靠回执,或页面跳转异常先查证据,不要立刻重跑
delivery 节点成功了,但结果没法用节点层 / 交付层上游没准备好可交付物,delivery 只是收口回查交付输入,不要把锅甩给 delivery

引用类错误,最容易把人绕晕

workflow 里一个高频问题,是节点之间“接上了”,但其实引用表达式本身不对。

这类问题常见会落在四种情况:

类型你可以怎么理解常见原因
empty引用是空的目标字段根本没填
invalid_format引用格式不对手动改过表达式,或复制时写坏了
missing_source上游来源不存在你引用了一个并不存在的节点或运行字段
missing_path来源在,但路径不对上游节点有输出,但字段名不是你写的那个

最稳的处理方式不是“猜一下字段名”,而是:

  1. 回到上游节点,看它真实产出了什么;
  2. 再看当前节点到底想拿哪一个字段;
  3. 必要时在中间加一个 Data operation,把输出整理干净再传下去。

浏览器型 workflow 最常见的误判

浏览器型 workflow 最危险的地方,不是“报错”,而是“你以为失败了,但它可能已经提交了”。

高风险场景包括:

  • 已经点过提交按钮;
  • 页面已经跳转;
  • 文件可能已经上传成功;
  • 对外系统可能已经写入了一部分状态。

所以遇到下面几种情况时,不要立刻整条重跑:

  • browser.submit_form 之后失败;
  • 截图节点没拿到证据;
  • 页面回执不稳定;
  • 审批后动作部分成功、部分失败。

先去看:

  • 浏览器截图证据
  • 外部系统实际状态
  • 本次 run 的最后成功节点

再决定是补跑后半段,还是新开一轮。

审批相关问题,很多时候不是系统错误

现象更真实的解释处理方式
流程停住,没有继续在等审批去审批列表确认是否待处理
找不到谁来批审批角色没选好或不明确回到 workflow / workpack 检查角色绑定
审批人看不懂该不该批审批节点上下文太少把摘要、证据、影响范围接到审批输入里
审批通过后效果不好审批只是允许继续,不是保证结果一定正确回到后续节点和目标系统排查

外部能力不可用时怎么判断

如果问题集中出现在这些地方:

  • browser
  • computer
  • knowledge base
  • 外部 connection
  • 生成类 Provider

而且多个 workflow 同时在同一类能力上出问题,那更像是外部能力不可用,不像是某一条 workflow 自己画错了。

这时候建议排查顺序:

确认是不是只有这一条 workflow 失败,还是同类任务一起失败。
确认连接、模型、浏览器或目标系统当前是否可用。
确认这次失败发生在真正对外动作前,还是对外动作后。
如果外部世界可能已经被改动,先查真实状态,再决定是否重跑。

按工作区继续往下查

如果你已经知道大概是哪一类任务在出问题,可以继续看按工作区拆开的细页:

最值得养成的三个习惯

  • 第一次先跑最小测试数据;
  • 外部动作前一定放审批;
  • 先找第一个失败节点,不要被最后一句错误带偏。

配套阅读