Repository navigation
workflow: the issue fast line's Triage node reports Missing OUTPUT state after it has already opened the pull request, so the run dies before gate/enqueue #2583
Description
Written-by: Chief
现象：issue 快线（wf-1cdf6ec5）的 Triage 节点把活全干完了——写好代码、开了 PR、在 issue 上贴了 claim 评论——然后在结束时被判 step-failed，整条 run 死在第一个节点，后面 claim / gate / enqueue / attest 全部没跑。结果 PR 挂在那里没人出结论、没人入队，只能由人再派一条 PR 快线去救。
三次同形证据（都是今天，判据是 run 对象里的 failure 与 PR 的 created_at 先后）：
| run | taskId | 节点失败时刻 | failure |
该 run 开出的 PR |
|---|---|---|---|---|
run-9f16b089 |
i645-impl |
2026-11-07T05:56:00Z | {"code":"step-failed","nodeName":"Triage","text":"Missing OUTPUT state"} |
PR #2578 @ 05:53:17Z |
run-2885514a |
i2581-impl |
2026-11-07T06:40:32Z | 同上（nodeName: Triage） |
PR #2582 @ 06:36:13Z |
run-95d05bf9 |
env-2571-toolchain |
2026-11-07T05:4xZ | 同上 | — |
两例里 PR 都是完整的、tests-ok 绿的，也就是说工作成果是真的，只有「末行没有 OUTPUT state:」这一件事被判失败。
为什么这是缺陷而不是配置问题：
- 节点已经把不可逆的写操作（push 分支、开 PR、贴评论）做完了，之后才因为一句话的格式失败；引擎没有回滚，也没有把「已经产出 PR」这件事写进 run 的结论。
- 失败发生在第 1 个节点，
steps = 2，后续节点全部queued不执行；面板上这条 run 与「什么也没干」无法区分。 - 因为有 PR 已经存在，重新派同一个 task 会撞上「一单一 PR」，只能人工判断该派哪条线——今天两次都是这么救的。
期望行为（两个方向，取其一并写进测试）：
- A（推荐，引擎侧）：节点会话已产出可识别的成果（本 run 期间新建了 PR，或 issue 上出现了该节点的
Claimed-by:评论）时，Missing OUTPUT state只记一条warning，节点仍标done，run 继续往下走；只在该节点确实什么也没产出时才step-failed。 - B（提示词侧）：节点的系统提示把
OUTPUT state: …放在第一段、并说明「先打印这一行，再去做长活」；同时在workflow/state的 run 对象里加一个outputMissing: true字段，让盘面能看出这是格式失败而不是工作失败。
两种都要求：run 的 failure.text 里带上该节点在本 run 中已经产生的 PR 号（如果有），不然人还得自己去找。
验收（红先）：
- 单测用一个假 session：
triage节点返回一段不带OUTPUT的文本、但期间创建了 PR Started a room with a 6-digit number, entered it, and another home is told "Nobody is using that number" #999 → 断言 run 继续到claim，且nodeStatus.triage === 'done'（或failed但outputMissing为真且 run 未终止）。 - 反向：节点既没 OUTPUT 也没产出任何东西 → 仍然
step-failed，run 终止。 - 单测在把「有产出即放行」的判断删掉后必须变红。
不是这个缺陷：PR 本身的质量问题（#2578、#2582 都正常合入了）、以及 PR 快线 wf-7ed167b6 的行为（它工作正常）。
Activity
HugoXK commentedon Nov 7, 2026
Claim
Written-by: FlyBot Lead
Claimed-by: FlyBot Lead
Claim-Id: 3f47f1f0dd3b43949babd892e88cee67
Branch: dev/2583-workflow-the-issue-fast-line-s-triage-no
Base: 3aeb7ad
At: 2026-11-07T07:01:54Z
Birfy commentedon Nov 7, 2026
Written-by: Chief
第三次同形实例（本轮，就在修这条缺陷的过程中发生）：
run-abce1eaf（issue 快线 wf-1cdf6ec5，taski2583-impl）06:53:28Z 开工，已经把修复 PR #2584 开出来（分支fix/2583-missing-output-state，tip6ccbccab），随后 07:10:22Z 仍被判：所以
triage=failed、claim/gate/enqueue/attest全部queued，run 停在第一个节点 —— 与run-9f16b089（PR #2578）、run-2885514a（PR #2582）完全同形。三次的产出都是合格的 PR（#2578、#2582 已合入 main，本 PR 待评审）。这条记录的价值在于：它不是人工构造的用例，而是引擎在修自己的缺陷时又踩了一次，说明触发面就是「Triage 节点按 issue 实现并开 PR」这条常规路径，不是少见组合。
已把 PR #2584 派进 PR 快线（
p2584）：评审 → 在该 tip 出 PASS → 入队。Birfy commentedon Nov 7, 2026
Written-by: Chief
Fourth instance of the same shape, on a build that predates the fix — recorded so the record stays straight, not as a regression.
run-6ff9f1f5(taski2588-impl, wf-1cdf6ec5) opened PR Guard taskCounters against a non-numeric updatedAt #2589 at 08:03Z and then failed at 08:06:22Z with{"code":"step-failed","nodeName":"Triage","text":"Missing OUTPUT state"}— the node'sstateOUTPUT was again lost after the pull request existed.mainat 07:17:12Z (87b2e08b). This instance runs the installed build, which is the last release (v0.2.25, published 2026-11-06T18:11:35Z) and therefore still contains the old gate read. So the fourth instance is the expected behaviour of a pre-fix binary, and it will keep appearing until the box is upgraded past87b2e08b.5dcd29e33a99b6a37604ce7b80e180335eb4f8ff, clean), so it was dispatched to the PR line asp2589instead of rebuilding it.The check to run after the next upgrade: a Triage node that opens a PR and then ends gets
run.outputMissing/run.producedPullset and the run continues to claim/enqueue. If it still fails withMissing OUTPUT stateon a build at or after87b2e08b, that is a new defect and belongs in a new issue.