主题
长链路任务卡住、重复执行或产物错位时怎样排查？
题型：问题排查 · 用统一标识还原一次节点尝试的完整轨迹。
排查顺序
- 先确认现象是状态停滞、实际未执行、重复执行，还是产物已经生成但绑定到了错误的 Episode/Shot，并记录受影响 Job 范围。
- 用 jobId、episodeId、shotId、nodeId 和 attemptId 串起控制面状态迁移、队列投递、Worker 领取、模型请求、Schema 校验和产物提交，找到最后一个可信事件。
- 检查节点租约与心跳是否过期、消息是否重投、多个调度器是否同时迁移状态，以及重试是否沿用了同一个幂等键。
- 对“结果未知”单独处理：模型或产物服务可能已经成功，但调用方超时。先按请求 ID 或内容摘要查询结果，不能直接再次触发有成本或有副作用的生成。
- 产物错位重点核对稳定实体 ID、输入版本、对象路径和提交清单，避免只根据数组下标或展示顺序关联 Shot。
止损与修复
先暂停受影响 Job 的下游调度，保留状态和原始响应快照；重复消费时关闭异常消费者或收紧租约，错位产物则隔离而不是覆盖正确版本。永久修复应落在条件状态迁移、幂等键、提交协议、版本校验或孤儿产物对账上，而不是简单增加重试次数。
验证与复盘
从故障前的稳定 Checkpoint 恢复一条小样本链路，验证同一消息重复投递不会产生第二份有效产物，且任务最终状态与产物清单一致。复盘补充卡住时长、租约过期、重复执行、未知结果和孤儿产物监控，并保留最小复现轨迹。
易错点
- 不要看到状态未更新就认定模型没有执行，先确认是否属于结果未知。
- 不要直接删除错误产物或强改成功状态，这会破坏后续对账证据。