Skip to content

fix(workflow): a ten-minute step deadline kills any node that does real work #1580

Closed

Description

@Birfy

Written-by: Chief

现象

workflow 插件把「节点等一个回复」的上限写死成 10 分钟:plugins/workflow/src/service.js:27 export const STEP_DEADLINE_MS = 10 * 60 * 1000,到点由 expireStep()(src/service.js:200-215)把整个 run 标记为失败,消息是「<节点> 超时:10 分钟没有回包,run 已标记失败」。

但这个插件自己的快线里,实现(claim)和审查(review)本来就是 20–40 分钟的活:拉 tarball、跑受影响套件、红先再回绿、commit/push、开 PR。于是凡是真要做事的节点几乎必然到点被杀,做过的部分一律不计——这不是节点写错,是等待上限配错。

今天的实测(2026-10-28,两条快线,全部在 10 分钟处被杀)

  • 09:00:54Z pr1498-land:Inspect 正常出结论(本 tip 无 PASS → route: review),Review 节点开始实审,10 分钟到点失败。
  • 09:01:00Z issue1462-build:Triage 在 08:53 判 ready 并指明复用已有 PR fix(core): route a card written through track_tasks to the board listeners #1568,Claim 节点接手,10 分钟到点失败。
  • 09:05:20Z issue-label-audit:Triage 已把四件事与范围定清,Claim 节点接手,10 分钟到点失败。
  • 对照:issue1546-build 只核对已有 PR、几分钟就完成,正常走完 5 步。

即:短节点正常,工时超过 10 分钟的节点一律失败。

期望

等待上限按工作流可配,默认值要够做完一件真活:

  1. 工作流定义新增 stepTimeoutMinutes(整数,1–120),缺省 45;
  2. expireStep() 用该值替换常量,超时消息报真实分钟数;
  3. 写入/更新工作流定义时校验该字段,非整数或越界拒绝(不要静默回落)。

验收

  • 单测:伪定时器把 deadline 走完 → run 标失败,消息带配置的分钟数;不配置时走 45 分钟缺省;非法值(0 / "abc" / 121)在写入定义时被拒。
  • 端到端可观察:给一条节点工时超过 10 分钟的 run 配 stepTimeoutMinutes: 45,它不再在 10 分钟处被杀。
  • npm run verify 绿;changelog.d/<issue>.fixed.md。

范围

plugins/workflow/src/service.js(常量、expireStep、定义校验)、必要的 plugins/workflow/client.js(面板展示该字段即可,不做新交互)、plugins/workflow/test/*.test.js、docs/subsystems/workflow.md。

为什么急

两条快线今天没有一条由节点产出的 PR 落地,全部死在 10 分钟这一条上;在它改掉之前,任何「把 issue 交给快线」的派活都是空转。

Activity

  1. added
    bugSomething isn't working
    area:automationScheduled tasks and automation
    on Oct 28, 2026
  2. Birfy commented on Oct 28, 2026

    @Birfy
    CollaboratorAuthor

    Written-by: Chief

    PR #1581 carries the fix, tip 83d202f0186648884f9e1d20a7215d0b162f6d1f.

    What it does: the per-step deadline is the workflow record’s stepTimeoutMinutes — an integer from 1 to 120, 45 when the record sets none, refused on write outside that range — instead of the ten-minute constant. workflow/create accepts the field, workflow/step-timeout sets it (null goes back to the default), workflow/state reports it, and the timeout message names the number that applied.

    Evidence at the tip: node --test test/deadline.test.js in plugins/workflow 11/11 green including three new cases; the whole plugin suite 142/143 with only test/host.test.js failing on a missing @deepseek-ai/dsh-llm harness in this checkout, which main does the same way; red first — with the ten-minute default restored and the workflow value ignored, the three new tests fail while the eight #1530 tests stay green.

  3. Birfy commented on Oct 28, 2026

    @Birfy
    CollaboratorAuthor

    Written-by: Triage

    agent-ready added (labels: bug, area:automation, agent-ready).

    Scope frozen — the fix is already in PR #1581 at tip 83d202f; do not rebuild it, verify/extend that branch.

    • Defect: the single step deadline at plugins/workflow/src/service.js:27 kills every node whose work needs more than ten minutes.
    • Scope: plugins/workflow/src/service.js (deadline from the workflow record stepTimeoutMinutes, integer 1-120, default 45; expireStep() uses it and the timeout message names the real minutes; create/update validate and refuse non-integers and out-of-range instead of falling back), plugins/workflow/client.js (display only), plugins/workflow/test/*.test.js, docs/subsystems/workflow.md, changelog.d/1580.fixed.md.
    • Acceptance: fake timers run the deadline out -> run marked failed with the configured minute count in the message; unset -> 45; 0, "abc" and 121 refused on write; a run configured stepTimeoutMinutes: 45 that takes more than ten minutes is not killed at ten; npm run verify green.
    • Tests first (must fail without the change): the three deadline cases in plugins/workflow/test/deadline.test.js.
    • Risk basis: plugin-only change, no host or generated-file surface.
  4. added
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    on Oct 28, 2026
  5. removed
    agent-readyMaintainer-approved spec: an agent may take it. Only maintainers set this; never in a template
    agent-prPull request opened by an agent
    on Oct 28, 2026
  6. added 3 commits that reference this issue on Oct 28, 2026
    59fb637
    22a1a38
    7ba3362
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:automationScheduled tasks and automationbugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions