[Bug] run_code 里调用 pwsh 杀进程后会话卡死，工具调用永不返回

[sryimnoob123]

Summary

run_code 里调用 tools.pwsh 杀进程（taskkill /F /T 杀 electron）时，pwsh 超时（timeoutMs 30000）后工具调用不返回，没有 tool/result 事件，整个回合卡死，无法继续。

Reproduction

1. run_code 内调用 tools.pwsh({ command: "taskkill /F /T /PID ", timeoutMs: 30000 }) 杀一个 electron 进程
2. 等待 pwsh 超时
3. run_code 的 await 永不 resolve，回合卡死

Versions

• Windows 11
• dsh 0.1.0-rc.7（DeepSeek Harness EAC v4Lite 4.4.0）
• 已核对官方 v0.1.0-rc.8 / v0.1.1-rc.1 / v0.1.1-rc.2 release notes，未见相关修复

Notes

• 杀的是独立的 electron 应用（桌面宠物），不是 dsh 自身进程
• dsh 主进程正常，其他会话不受影响
• 会话标签页关闭时，session.cancel 返回 "session not found (not attached)"
• 推测：pwsh 超时被 kill 后，worker 的管道句柄未回收，await 永久挂起

[sryimnoob123]

补充:完整复现与机理(已实测确认)

我在本地反复实验后,找到了稳定复现的触发条件,和原帖略有不同——不一定要杀进程,关键在于「带重定向启动常驻控制台进程」。

100% 复现代码

await tools.pwsh({
  command: "Start-Process node -ArgumentList '-e','setInterval(()=>{},1000)' -RedirectStandardOutput \"$env:TEMP\\r.log\" -RedirectStandardError \"$env:TEMP\\r.err.log\"",
  timeoutMs: 12000, description: "repro"
})

结果: 工具调用永不返回(实测 67 秒+ 无 tool/result), 12 秒超时完全不生效。

关键现象: 手动杀掉那个 node 进程,卡住的调用 1 秒内返回。 卡点与孙进程持有的句柄直接绑定。

触发边界(逐项实测)

变体	结果
Start-Process node(不带重定向)	正常返回(约 2.4 秒)
Start-Process node -RedirectStandardOutput/-RedirectStandardError	永久卡死, timeoutMs 失效
Start-Process electron(GUI 程序)	正常返回(GUI 程序不继承控制台句柄)
run_code worker 内直接 spawn 子进程(stdio inherit)	正常返回(worker 管道无缺陷)
taskkill /F /T 杀干净的 electron 树	正常返回(数百毫秒)

现场观察

卡死期间: 执行命令的 PowerShell 进程已经退出, 只有 Start-Process 拉起的 node 孙进程还活着。DSH 的 subprocess 层在等句柄/管道完全释放才结算结果, 这个等待没有超时兜底。

历史卡死(14 分钟那次)结算时间恰好等于用户手动停止的时刻——不是调用完成, 是中止时被强制结算的。

建议修复

1. subprocess 结算(settle)加无条件硬超时: 子进程退出后固定几秒强制结算, 不依赖管道/句柄状态;
2. 工具结束后收割孤儿进程树(现在是既不等待也不清理, 孙进程变孤儿);
3. 或在文档警告: 不要在 pwsh 里用 -RedirectStandardOutput 启动常驻程序。

环境: Windows 11, dsh 0.1.0-rc.7 (EAC v4Lite), 与第三方插件/桌宠无关, 是执行层自身的问题。

[argszero]

感谢详尽的复现与变体测试，表格质量很高。我对照公开仓库源码（v0.1.1-rc.2，以及您所用的 0.1.0-rc.7 tag）逐一核对后，发现「结算无超时兜底」这一条与源码不符；另有一条缺口仍然成立。附判别实验帮助定位。

1. subprocess 结算层已有强制兜底（rc.7 与 rc.2 均有）
subprocess-local/spawn.ts 在直接子进程 exit 事件后启动 pipeDrainTimer：若 stdio close（管道 EOF）未在 graceMs 内到达，则强制结算并返回已收集输出；pwsh-local 默认 graceMs 为 3 秒。代码注释原文正是针对此场景：A surviving descendant that inherited a pipe must not hold the outcome open indefinitely。也就是说，「孙进程持有管道导致结算无限等待」在公开代码里最多延迟 3 秒。

2. timeoutMs 接线完整
pwsh-local 前台路径是 deadline(outer signal, timeoutMs) 与 await handle.done 的组合；超时 abort 触发 terminate，Windows 上走 taskkill /T /F 杀整树，随后 exit 事件 3 秒内结算。按公开代码，12 秒超时场景最坏约 15 秒内必返回结果。您实测 67 秒以上不返回，与公开源码的结算路径不兼容。

3. 因此矛盾指向两个可能

• 您的构建（EAC v4Lite 4.4.0）携带的 subprocess 层与公开仓库不一致（内置了更早的 vendored 代码、无 pipeDrainTimer）——建议在构建产物中搜索 pipeDrainTimer 确认；
• 卡点不在 subprocess 层，而在工具结果回传通道（例如 run_code worker 桥接层）。

4. 三个一分钟判别实验

• 不经 run_code、直接调用 tools.pwsh 执行同样的 Start-Process 命令：仍挂起则属 shell/subprocess 层（与公开源码矛盾，请附构建内 spawn 代码）；约 5 秒内返回则卡点在上层通道；
• 命令末尾追加分号与 Write-Output 标记：若标记不出现，说明 powershell 自身未退出（Start-Process 带重定向在部分 PowerShell 版本存在保持父进程句柄/控制台的行为），属执行器层问题；
• 检查构建内 spawn 代码是否存在 exit 后的强制结算定时器。

5. 仍然成立的真缺口：正常完成不收割存活孙进程
公开代码里 settle 只 resolve、不杀树（terminate 仅在 abort 或 host-exit 时触发）。Start-Process 拉起的 node 在工具正常结束后成为孤儿继续存活——您建议的「工具结束后收割孤儿进程树」确实缺失。注意语义设计：后台启动常驻进程（dev server 等）是合法用法，直接杀树会破坏它，建议做成显式策略（仅对 collect 模式与工具作用域生效，或提供 detach 选项）。

6. 家族关联：与工具不可抢占/超时家族（#3400/#3477）以及 Windows 句柄相关审计（#3466）同源——孙进程继承管道句柄是 Windows 经典现象。另注：run_code 在 rc.2 已重构（extensions/run-code 并入 core code-runtime，旧的 readline 逐行监听已移除），原复现路径在 rc.2 上行为可能已变化，建议在 rc.2 上重测。