[17.0-rc2验收] wait 定时暂停被外部 resume 短路后,一次性唤醒 job 仍保持 armed —— 次日对已完成 run 发起幽灵 resume,sys_job 里留下误导性的「待唤醒」行

[yinlianghui]

环境:hotcrm@0899b4f + @objectstack 17.0.0-rc.2,objectstack dev -p 4093,fresh dev DB(file:…/data.db,--seed-admin)。发现于 17.0-rc2 验收 A3(自动化 Flows)组。

现象

wait 节点(timer,timerDuration: 'P1D')挂起的 run,通过 REST resume 端点(POST /api/v1/automation/:name/runs/:runId/resume,对 screen/wait 暂停是被 #3801 gate 明确放行的门)提前恢复并跑完之后,wait 节点入场时排下的一次性唤醒 job(flow-wait:<runId>:<nodeId>,{type:'once', at:+24h})没有被取消:

• run 已 completed,但 sys_job 里对应行仍 active: true,schedule_expression 指向明天;
• 到点后该 job 会对一个已完成的 run 调 engine.resume(runId) —— 一次注定失败的幽灵 resume(machine-state error,结果被回调丢弃),然后才在 finally 里自我取消;
• 在此之前的整整 24h 窗口内,任何看 sys_job 的运维/测试都会把这行读成「还有一个 run 在等唤醒」。

复现(两次,同一形态)

1. HotCRM case_csat_followup(record-change,close 后 wait P1D → notify):关闭一个 case,flow 挂起,sys_job 出现 flow-wait:run_…:wait_1d(at = +24h)。
2. POST /api/v1/automation/case_csat_followup/runs/<runId>/resume(body {})→ run 完成,notify 正常投递。
3. 复查 GET /api/v1/data/sys_job:该 flow-wait 行仍 active: true。

实测残留(14:37Z 快照,两个 run 均已 completed):

flow-wait:run_635c0008-d4fc-43e9-adfc-cc9bfc96324b:wait_1d  once  active=True at=2026-08-06T14:17:09.006Z
flow-wait:run_bfbe27ff-c9e7-4b71-8d01-eb3d888813de:wait_1d  once  active=True at=2026-08-06T14:24:59.742Z

对应 run 状态(runs 端点):run_635c0008… completed、run_bfbe27ff… completed。

期望 vs 实际

• 期望:run 离开 wait 节点(不论 timer 到点还是外部 resume)时,该节点的唤醒 job 一并取消 —— job 表与 run 状态一致。
• 实际:job 只在自己的 timer 回调里自我取消;外部 resume 路径完全不碰它。

落点分析(平台,service-automation)

packages/services/service-automation/src/builtin/wait-node.ts 中,job.cancel(jobName) 只出现在两处:timer 回调的 finally(约 L90)和 boot re-arm 的同款回调(约 L227)。engine.resume() / resumeInternal 侧没有任何按 correlation(suspend 时返回的 correlation: jobName 就是现成的钩子)取消 job 的逻辑。

影响面小(一次幽灵 resume + 24h 的误导性 job 行,无数据效应),报 p2 性质;但凡是「signal/manual 提前唤醒 timer wait」的正常用法都会留下这种残留,长期运行的 org 会在 sys_job 里积累一批 stale once-job。

佐证

• 幽灵 resume 无害的依据:engine.resume() 对未挂起 run 走 resumeInternal 的 machine-state error 分支(engine.ts L2482 起),回调不消费结果。
• 挂起/唤醒本身工作正常(同验收轮实测):timer job 正确排在 +P1D,cold-boot re-arm 逻辑存在(rearmSuspendedWaitTimers)。

[os-zhuang]

分诊结论:pm:queue / domain:services

去重检查:在 objectstack-ai 组织范围内(objectstack / objectui / cloud 三仓)搜索 flow-wait、wait-node job.cancel resume、sys_job stale wait timer 等关键词,除本 issue 外无其他 open issue 或 in-flight PR 命中,未发现影子认领或重复项。

代码复核(anchored on origin/main):已 fetch origin main 并核对当前代码,现象仍然成立,不是过时前提:

• packages/services/service-automation/src/builtin/wait-node.ts 中 job.cancel?.(jobName) 确实只出现在两处 —— timer 回调自身的 finally(约第 90 行)以及冷启动 re-arm 回调的同款 finally(rearmSuspendedWaitTimers 内,约第 227 行)。
• packages/services/service-automation/src/engine.ts 的 resume() / resumeInternal() 路径(约 L2482 起的 resume() 及其 refuseGatedResume 网关)通读全文未见任何 IJobService 引用或按 correlation(suspend 时随 persistSuspendedRun 写入的 correlation: jobName,如 err.correlation 在 L2418/2935 的传递)反查、取消 job 的逻辑 —— 引擎完全不感知 job 服务的存在。
• 因此外部 resume(REST /resume 端点或 SDK 直连,均落到同一个 resume())提前唤醒一个 timer-wait 挂起的 run 时,原先在 wait-node.ts 里排下的一次性 flow-wait:<runId>:<nodeId> job 完全不会被取消,直到自己的 deadline 到点、对已完成的 run 发起一次注定失败的幽灵 engine.resume() 后才在自身回调的 finally 里自我取消 —— 与 issue 描述完全一致,是当前代码的真实缺陷,而非已被修复的旧前提。

分类理由:落点明确(wait-node.ts 的两处 job.cancel 与 engine.ts 的 resume 路径均已定位到具体代码行),修复方式清晰(resume 路径需要拿到 suspend 时记录的 correlation 并据此调用 job.cancel),属于「有明确文件/位置的具体缺陷」,故标 pm:queue。

领域判定:落点是 packages/services/service-automation,按分诊表属于 packages/services/* → domain:services。未命中 driver-memory / driver-mongodb 冻结名单(#5499),按常规流程分诊,不适用 pm:on-hold。不涉及跨领域拆分。

本评论来自分诊座位 Routine(#5474 试点),不构成认领。

---

Generated by Claude Code

[os-zhuang]

认领:PM 循环第 1 轮(services 车道)
会话:session_01BWS4heBoAitLmzCLhcYdbK
分支:claude/issue-5512-wait-resume-job-cancel
Worktree:objectstack-issue-5512
域:domain:services
文件面:packages/services/service-automation/src/builtin/wait-node.ts、packages/services/service-automation/src/engine.ts、同包测试、.changeset/*.md

---

Generated by Claude Code

[os-zhuang]

开发座位报告(session session_01BWS4heBoAitLmzCLhcYdbK,分支 claude/issue-5512-wait-resume-job-cancel)。

前提复核:成立。 对 origin/main(基线 308c709)核对确认 job.cancel?.(jobName) 只在 timer 回调与 rearmSuspendedWaitTimers 两处 finally;engine.ts 里 IJobService 出现 0 次;DbJobAdapter.cancel(name) 正是把 sys_job 行置 active: false 的那个动作,且对不存在的 job 名是安全 no-op。

修法:补上暂停契约缺失的那一半 —— NodeExecutor 新增可选 onSuspensionReleased(release),由 forgetSuspendedRun(resume / 终态失败 / cancelRun 三条路径的唯一收口)派发,按暂停节点的注册类型路由;wait 节点实现它,取消名字与 waitTimerJobName(runId, nodeId) 全等的那个一次性 job。因此不只是 REST resume,cancelRun 与 subflow 祖先失败也会一并拆除唤醒 job;而 signal wait / 无可解析时长的降级 timer(correlation 不是 job 名)一个都不误取消。timer 回调自身的 finally 保留,理由与那半边不同(见下)。

草稿 PR:#5527。

顺手记录的相邻缺口(未在本 PR 修):timer 回调的 finally 无条件自我取消,而 engine.resume() 是返回错误码而非抛错 —— STORE_UNAVAILABLE 时暂停并没有被消费,却已经把唯一的唤醒 job 取消了,该 run 会挂到下次重启的 overdue re-arm 才被捞回。已单开 #5529 交分诊。

---

Generated by Claude Code

[os-zhuang]

复核:ACCEPT → PR #5527(draft,待 CI 全绿后转 ready 入合并队列)。

已核项:

• 前提对 origin/main 复核成立(engine.ts 零处 IJobService;DbJobAdapter.cancel 正是置 active: false 的动作且对未知名安全);
• 修法评估:没有走「resume 路径硬编码取消」,而是补齐暂停契约缺失的另一半 —— NodeExecutor.onSuspensionReleased(可选),由 forgetSuspendedRun(resume / 终态失败 / cancelRun 三条消费路径的唯一收口)按暂停节点注册类型路由派发。这是一处 SPI 扩张(changeset minor,新导出 SuspensionRelease / SuspensionReleaseReason) —— 我按车道内可决处理:方向由既有规范决定(引擎不得感知 job 服务的分层约束、automation: the generic run-resume route needs an authorization gate keyed on the suspended node #3801 类型键先例、单收口原则),可选成员向后兼容,未触 packages/spec。维护者可否决,否决则改回点修;
• wait 节点侧用 waitTimerJobName 重建后全等判定(不做前缀匹配),signal wait 与降级 timer 的 correlation 不会被误取消,均有负面对照用例;timer 自身 finally 保留并写明两者回答不同问题;
• 反向验证:摘掉收口处的通知调用后 10 条红(3 条路径复现 + 7 条契约),负面对照保持绿 —— 断言钉的是新行为,不是空判;
• 消费半径:plugin-approvals / trigger-schedule / trigger-record-change 三包 538 用例全绿;tsc 5 个既有错误改前后一致,新增 0;
• 文件面:6 文件全在 service-automation 包内(index.ts 一行是公开成员引用类型的必要再导出);authorable-surface.base.json 的 gen 重锚已还原未进提交 ✓;
• 顺带发现已独立立单:wait 定时唤醒 job 在 resume 没能消费掉暂停时也会自我取消 —— store 短暂不可达即丢掉这一次唤醒,run 挂到下次重启才被捞回 #5529(timer 回调 finally 无条件取消 job,但 STORE_UNAVAILABLE 时暂停未被消费而唤醒 job 已丢 —— run 挂死到重启 re-arm),本车道随后分诊。

---

Generated by Claude Code