Flow 监控与问题修复

去哪看 Flow 运行、失败时怎么定位到出问题的节点，以及您真正会遇到的五类失败——每类给现象、原因和您自己能做的修复步骤。

看什么#

• 运行监控（Integration → Runs）：所有 Flow 执行都在一个列表——Flow 名与版本、触发方式（定时/事件/手动）、状态（running、success、failed、retrying）、耗时、处理条数。按状态筛选只看失败的。
• 运行详情：点开一次运行，逐节点看——每步的输入快照、输出快照，失败步还有确切的报错信息。永远从这里开始：失败节点和它的输入通常直接指出原因。
• 日志与死信（Integration → Logs）：彻底失败的条目进死信队列，带着 Flow、节点和报错。修好原因后，重放（replay）死信把那条重新处理；不再需要的就丢弃（discard）。
• 连接健康：运行在第一个节点就报认证错，那是连接的问题不是 Flow 的问题——连接自己的「测试」按钮几秒就能复现。

下面五类失败覆盖了您会见到的几乎所有情况。每类都有：现象长什么样、为什么发生、怎么修——全部是您在界面上自己能做的，不用提工单。

1. 凭证过期或失效#

• 现象：运行在第一个节点就报 401 / 认证失败；连接「测试」同样失败。经常是跑了几周后突然开始。
• 原因：对方平台让凭证过期或轮换了——token 都有寿命（如 Wish 的 access token 30 天；部分 OAuth 用户 token 只有几小时），有人在平台后台重新生成 secret 也会变。
• 修复：①去平台拿新凭证（目录里对应条目写了确切路径）；②打开连接，粘新值，保存；③点连接「测试」到通过为止；④把故障期间产生的死信重放掉。

2. Mapping 缺失或类型不对#

• 现象：运行在中间节点失败，报错如「字段 X 必填」「SKU 未映射」，或值被以类型不对拒掉（该是数字的地方来了文本、日期格式不对）。新订单带新 SKU 是最经典的触发点。
• 原因：Mapping 期望的源字段在那单上是空的或不存在；两边系统对字段类型理解不一致；或某个渠道 SKU 从没和 OMS 产品配过对。
• 修复：①打开失败运行，看是哪个节点、哪个字段；②SKU 未映射的，去产品映射待处理列表配对；③字段缺失/类型不对的，打开 Flow（或连接）的 Mapping，把源字段映射对，或给该字段加默认值/转换；④试跑确认，改了 Flow 就重新发布，然后重放死信。

3. 对方平台限流#

• 现象：运行状态显示「retrying」，或报 429 /「请求过多」。爆发式调用会加重——如手动大批量拉单之后、或整点多个 Flow 同时触发时。
• 原因：每个平台都对账号每分钟/每小时的 API 调用量设了上限。连接器本身会退避重试——「retrying」就是这个意思——但持续爆发仍会耗尽额度。
• 修复：①偶发「retrying」什么都不用做——通常自己就重试成功了；②反复出现就调低连接/Flow 的拉取频率；③把多个 Flow 的定时错开，别让它们同一分钟打同一个平台；④积压重试期间不要反复手动拉单。

4. Webhook / 回调失败#

• 现象：该靠推送到达的数据一直不来——追踪号或履约确认迟迟不回、新订单通知停了——但手动拉取正常。日志里有 webhook 投递报错。
• 原因：发送方平台没投递成功（临时网络问题）、换凭证时订阅被注销、或连接停用再启用后回调没有重新注册。
• 修复：①看 Integration → 日志里的 webhook 报错和时间——已经停了的短时爆发不用管；②测试连接，多数平台在测试成功时会重新校验回调注册；③推送还是不来，停用再启用连接，强制重新订阅；④手动拉一次把漏掉的补回来，再盯下一个真实事件是否到达。

5. 数据格式问题#

• 现象：同一连接上有的单成功、有的单失败——某个订单因地址不合法被拒、电话格式不对、邮编解析不了、或重量数字里混了单位。
• 原因：数据本身——它在源平台或源单据里的样子——不符合接收方的格式规则。Flow 和凭证没问题，是那一单的数据有问题。
• 修复：①打开失败运行，看被拒的是哪一单、哪个字段——报错会点名；②能在源头改的就改源头（把订单或平台上的地址/电话改对）；③同一平台总是出同一种格式毛病，就在 Mapping 里一次性处理：给该字段加默认值、去空格或转换；④把改好的那单的死信重放。