[verify] 端到端验证从构造上绕开了挂起 run 的持久化路径(harness 写死 suspendedRunStore: 'memory')

[os-zhuang]

#4420 的后续 —— 关于"为什么这个 bug 能一路发版"。

问题

packages/verify/src/harness.ts 挂载自动化插件时写死了 suspendedRunStore: 'memory'。也就是说 dogfood / e2e 这一层从构造上就不可能碰到 DB-backed 的挂起 run 存储:被验证的永远是内存路径。

结果是覆盖率上有一条整齐的缝:

• 单测覆盖了引擎侧的持久化(suspended-run-store.test.ts 用假表跑 suspend → restart → resume);
• e2e 覆盖了业务侧的审批链路(但全程单进程、纯内存);
• 而两者中间的装配——对象有没有注册、表有没有建、store 有没有真的接上——没有任何一层真正跑过。

#4420 恰好就长在这条缝里:store 挂在一张没建的表上,每次写盘失败都被吞进一条 warn,挂起照常"成功",直到下次重启才暴露。#4460 补了针对装配的单测,但 e2e 这一层的盲区还在。

期望

至少一条走 durable store 的端到端验证,把"挂起真的落库了"变成可断言的事实,而不是靠日志推断。最小形态:

• 用真实驱动跑一个含 approval(或任意可挂起节点)的流程,让它挂起;
• 断言 sys_automation_run 里确实出现了对应的 paused 行(不是断言"没报错");
• 冷启动一个新 kernel,resume 能继续走对分支。

注意 #4460 之后 hasSuspendedRun() 可以直接用来做这个断言。

另外值得顺带确认的是:harness 当初写死 'memory' 是为了跑得快、还是因为持久化在那个环境跑不通。如果是后者,那本身就是这个 issue 更值得修的部分。

参考

• packages/verify/src/harness.ts(suspendedRunStore: 'memory')
• packages/services/service-automation/src/plugin-suspended-run-wiring.test.ts(fix(automation,approvals): 审批决策不能在流程原地不动的情况下"成功" (#4420) #4460 新增,单测层的装配覆盖)
• packages/services/service-automation/src/suspended-run-store.test.ts
• [automation/approvals] 进程重启后审批决策静默失效:挂起 flow run 仍只存内存(#1518 标记 COMPLETED 但 17.0.0-rc.1 未生效),approve 落库却永不推进且零报错 #4420 / fix(automation,approvals): 审批决策不能在流程原地不动的情况下"成功" (#4420) #4460

[os-zhuang]

已由 #4502 修复（已合入 main，commit 5a84d4148）。把说明留在这里，因为这是下一个读者最可能来的地方 —— 尤其是本 issue 末尾那个问题的答案。

先回答 issue 里的那个问题

值得顺带确认的是：harness 当初写死 'memory' 是为了跑得快、还是因为持久化在那个环境跑不通。如果是后者，那本身就是这个 issue 更值得修的部分。

是前者 —— 便利性妥协，不是技术限制。 持久化在这个 harness 里跑得通：把 store 换成插件自己的 'auto' 默认值之后，既有 dogfood 套件分片 1 的 38 个测试文件、239 个用例全部通过，一个既有用例都没失败。也就是说不存在「测试原本钉着错误行为」需要处置的情况，也不存在「新实现真的坏了」。

根因

packages/verify/src/harness.ts 挂载自动化插件时写死 suspendedRunStore: 'memory'。这不是「测得不够」，是测不到：DB-backed 挂起存储从构造上就不可能被任何 dogfood/e2e fixture 触及。于是就有了 issue 描述的那条缝 —— 引擎侧持久化有单测（用假表），业务侧审批链路有 e2e（纯内存），而两者中间的装配（对象有没有注册、表有没有建、store 有没有真的接上）没有任何一层跑过。#4420 恰好长在那里。

改动

• harness 改用插件自己的 'auto' 默认值 —— objectstack dev / serve 得到的同一套装配；
• automation 选项现在也接受 { suspendedRunStore: 'auto' | 'memory' }，想要旧行为的 fixture 必须显式要；
• 新增 databaseFile，让数据库可以落到文件而非 :memory:。

新增 packages/qa/dogfood/test/flow-durable-suspend.dogfood.test.ts + fixture：一个含 screen（可挂起）节点的流程，走真实驱动、真实 HTTP。

断言的是事实，不是「没报错」

按 issue 的要求（「断言 sys_automation_run 里确实出现了对应的 paused 行，不是断言『没报错』」）：

• sys_automation_run 真的存在且可查 —— 就是 [automation/approvals] 进程重启后审批决策静默失效:挂起 flow run 仍只存内存(#1518 标记 COMPLETED 但 17.0.0-rc.1 未生效),approve 落库却永不推进且零报错 #4420 缺的那张表；
• 暂停真的落成一行 paused，按 id 读回来，且带着 rehydrate 所需的每一个字段：node_id、resume 闸门（automation: the generic run-resume route needs an authorization gate keyed on the suspended node #3801）所依赖的 node_type、可解析且含触发输入的 variables_json、steps_json，以及 screen_json；
• resume 消费掉那一行（404），并在 run_ 前缀下留下 completed 的终态历史行 —— 正是 [automation/approvals] 进程重启后审批决策静默失效:挂起 flow run 仍只存内存(#1518 标记 COMPLETED 但 17.0.0-rc.1 未生效),approve 落库却永不推进且零报错 #4420 会产生的僵尸形态的反面；
• 屏幕契约（screen flows: resume performs no server-side validation — missing required fields and undeclared keys all complete the run #4477）对着持久化的 screen_json 生效，且拒绝之后那行仍在、合法提交仍能落。

一个未做完的部分，明写在这里

issue 的第三条最小形态是「冷启动一个新 kernel，resume 能继续走对分支」。这条没有做到，而且没有用放松断言的方式假装做到。

诊断过程：新 kernel 用同一个 databaseFile 起来后，sys_automation_run 里查不到那行 paused。用探针进一步确认 —— 连普通的业务记录也不在，而表结构是在的。这就把归因定死了：不是挂起存储的问题，是 harness/驱动层「文件数据库在进程内重启后不保留行」的问题（sqlite-wasm 默认 persist: 'on-disconnect'，而 kernel 关停似乎没走到那个 flush）。

所以：冷启动那半在测试文件头部明确标注为 KNOWN GAP 并说明为什么不假装它通过；该持久化缺口另行记录，等它修好之后，这个文件最自然的下一个用例就是它最初被写出来的那个。

顺带：这条新 e2e 第一次跑就抓到了一个真 bug

#4515 —— AutomationEngine.getSuspendedScreen 只读内存热缓存（方法是同步的，没能力问存储），所以进程重启后，一个 resume 还能打通的挂起 run，GET …/runs/:runId/screen 却 404。修它要把公开契约上的方法改成异步，属于协议破坏性变更，按 AGENTS.md #10 单独立 issue 未认领。

这恰好是本 issue 的价值论证：修「验证手段本身失效」的回报，就是这类缺陷今后能被测出来 —— 它在第一次运行时就兑现了。

文档与 changeset 因合并队列锁分支而拆在 #4517。

---

Generated by Claude Code