问题概述
@dsh-external/workflow 的 engine.js 在多处直接迭代 agent.session.events(视为可迭代属性)。但 DSH 0.1.2-rc.1 / 0.1.5-rc.1 的 Session 类不存在公开的 events 属性,事件访问 API 为 snapshotEvents() / ownEvents()。因此 spawn 出的子任务一完成就抛 TypeError: agent.session.events is not iterable,导致子任务 failed、run 永远卡在 running,进而拖垮 host。
环境
- DSH:
0.1.2-rc.1(npx 运行)与 0.1.5-rc.1(均验证 Session 无 events 属性)
- 插件:
@dsh-external/workflow v0.1.3(peers ^0.1.0-rc.5,与 0.1.2-rc.1 匹配,可以安装);v0.1.4(bug 未修)
- 平台:Windows 11,Node 24
复现步骤
- DSH 0.1.2-rc.1 下安装
@dsh-external/workflow@v0.1.3 到任意 profile(已在 pnpm-workspace allowBuilds 中声明包名)。
- 通过
run_workflow name=<capsule> 运行任意会 spawn 子 agent 的 workflow capsule。
- 等待第一个子任务(spawn 的 localAgent)完成。
实际行为
子任务完成回调触发 usage/telemetry 统计,立即抛出:
TypeError: agent.session.events is not iterable
调用链(lib/engine.js,v0.1.3 与 main 分支一致):
usageOf(agent) —— for (const event of agent.session.events) { ... }
observedToolEvidence(agent) —— 同上
childRecordedCompleted(agent) —— const end = [...agent.session.events].reverse().find(...)
latestAssistantText(childRun.localAgent, ...) 路径同样触发
错误沿 spawn 完成路径向上传播:子任务被标记 failed → run 的状态机没有收到完成终态 → run 永远卡在 running → profile 宿主进程随后退出。
预期行为
插件应使用 DSH Session 的公开事件读取 API:session.snapshotEvents() 或 session.ownEvents()(二者在 dsh-session 的类型定义中公开,见 dsh-session/lib/types/index.d.ts),而不是直接访问不存在的 session.events 属性。
DSH Session 公开 API(0.1.2-rc.1 与 0.1.5-rc.1 均如此):
snapshotEvents(fromSeq?: SessionLogOffset, toSeqExclusive?: SessionLogOffset): readonly SessionEvent[];
ownEvents(): readonly SessionEvent[];
// ❌ 不存在 session.events 属性
建议修复
将 engine.js 中三处 agent.session.events 统一替换为 agent.session.snapshotEvents()(或 ownEvents()),并对返回值保持只读使用(snapshotEvents() 返回冻结快照,[...] 展开仍然可用)。
影响面
附注
- 已通过
validateWorkflowCapsule/source 静态校验,说明问题纯粹在运行时引擎对 Session API 的假设。
- 本地已验证把 spawn 流程改造为不走 capsule(改用宿主原生 subagent/workflow 工具编排)后可正常运行,佐证故障点确在 engine 对
session.events 的直接迭代。
问题概述
@dsh-external/workflow的engine.js在多处直接迭代agent.session.events(视为可迭代属性)。但 DSH 0.1.2-rc.1 / 0.1.5-rc.1 的Session类不存在公开的events属性,事件访问 API 为snapshotEvents()/ownEvents()。因此 spawn 出的子任务一完成就抛TypeError: agent.session.events is not iterable,导致子任务 failed、run 永远卡在 running,进而拖垮 host。环境
0.1.2-rc.1(npx 运行)与0.1.5-rc.1(均验证 Session 无events属性)@dsh-external/workflowv0.1.3(peers^0.1.0-rc.5,与 0.1.2-rc.1 匹配,可以安装);v0.1.4(bug 未修)复现步骤
@dsh-external/workflow@v0.1.3到任意 profile(已在 pnpm-workspaceallowBuilds中声明包名)。run_workflow name=<capsule>运行任意会 spawn 子 agent 的 workflow capsule。实际行为
子任务完成回调触发 usage/telemetry 统计,立即抛出:
调用链(
lib/engine.js,v0.1.3 与 main 分支一致):usageOf(agent)——for (const event of agent.session.events) { ... }observedToolEvidence(agent)—— 同上childRecordedCompleted(agent)——const end = [...agent.session.events].reverse().find(...)latestAssistantText(childRun.localAgent, ...)路径同样触发错误沿 spawn 完成路径向上传播:子任务被标记 failed → run 的状态机没有收到完成终态 → run 永远卡在
running→ profile 宿主进程随后退出。预期行为
插件应使用 DSH Session 的公开事件读取 API:
session.snapshotEvents()或session.ownEvents()(二者在 dsh-session 的类型定义中公开,见dsh-session/lib/types/index.d.ts),而不是直接访问不存在的session.events属性。DSH Session 公开 API(0.1.2-rc.1 与 0.1.5-rc.1 均如此):
建议修复
将
engine.js中三处agent.session.events统一替换为agent.session.snapshotEvents()(或ownEvents()),并对返回值保持只读使用(snapshotEvents()返回冻结快照,[...]展开仍然可用)。影响面
^0.1.3-alpha.1,0.1.2-rc.1 装不上。附注
validateWorkflowCapsule/source 静态校验,说明问题纯粹在运行时引擎对 Session API 的假设。session.events的直接迭代。