[bug] 后台任务挂死导致对话整体冻结：job_output(wait:true) 无活性信号，agent 陷入重复等待

[ZichengGurrr]

一句话摘要

后台任务里的子进程挂死（6 分钟 0 CPU、无网络、无子进程）后，job_output(wait: true) 把整个回合锁死；超时返回的信息只有 [status: running]，没有任何“最后输出时间 / 进程活性”数据，agent 无法区分“慢”和“卡死”，于是再次 wait: 240s，形成无限循环。最后只能靠外部人工杀进程才能恢复。

环境

项	值
dsh	0.1.0-rc.6（dsh web profile，Windows）
Node	v24.19.0
pnpm	11.7.0
OS	Windows（PowerShell 5.1 承载 + pwsh 工具）

完整时间线（Asia/Shanghai，2026-08-15）

时间	事件
01:06:53	agent 通过 pwsh 工具以 run_in_background: true 启动后台任务（job_id: pwsh-2），脚本共 5 步：构建 bridge 插件 → 注册进 web profile → 构建 Chrome 扩展 → 复制到 ~/.dsh/browser-extension → 打印 profile 状态
01:06:56	agent 调用 job_output(job_id: pwsh-2, timeout_ms: 300000, wait: true)
01:06:57–59	第 2 步 pnpm exec dsh plugin --profile web add <link 绝对路径> 中的 pnpm add 写完所有文件：profile 的 package.json、pnpm-lock.yaml、node_modules junction、.modules.yaml、.pnpm-workspace-state-v1.json，并打印了完成摘要（"Done in 2.2s using pnpm v11.7.0"）
01:06:59–01:13:53	pnpm add 进程（PID 27956）存活但完全静止：4 秒采样 0 CPU、0 网络连接、0 子进程，持续约 6 分钟。因为脚本里该步骤的输出接了 2>&1 | Select-Object -Last 6（缓冲全部输出、管道关闭才吐出），pnpm 的完成摘要被压在管道里；期间 job_output 读到的只有 "=== 2. 注册进 web profile ===" + [status: running]
01:11:56	第一次 300s 等待超时，返回：无新输出、[status: running]
01:11:59	agent 误判（原话："pnpm add may be slow (resolving/linking). Let me wait for the job to complete."），再次 job_output(wait: true, timeout_ms: 240000)——进入“每次等 4-5 分钟”的循环，对话从用户视角完全冻结
~01:13:53	人工从外部杀掉挂死的 pnpm add 叶子进程
数秒内	整条链（cmd → dsh plugin add → pnpm exec → pwsh）全部退出；被缓冲的输出瞬间吐出（证实 pnpm 早已在 2.2s 内干完活）；脚本继续第 3-5 步：扩展构建（431ms）并复制完成（01:14:02–03）
01:14:03	任务成功结束，job_output 返回完整输出，对话恢复

后遗症：dsh plugin add 的 bundles 调和步骤只在 pnpm 退出码为 0 时执行（lib/plugin-*.js 中 if (exitCode === 0) reconcilePlugins(...)），被杀进程退出码非 0，所以 dsh.profile.bundles 没有自动补上新插件；agent 事后自己检查并手动修正。任务最终全部完成。

根因归属

挂死本身大概率不是 DSH 的管道问题，而是 pnpm 11.7.0 在 Windows 上“干完活、打印完摘要后不退出”的已知症候（见 pnpm#9530：pnpm install 完成后无限挂起 - Windows；另见 Windows 句柄相关问题 pnpm#9961）。我核实过 DSH 侧的两处实现，都没有“管道不读导致死锁”的经典错误：

• dsh-subprocess-local 对收集型流持续 stream.on("data") 排空，超出内存上限落盘 spill 文件，不会背压；
• dsh plugin 命令本身用 spawnSync(pnpm, { stdio: "inherit", shell: true }) 直通继承句柄，不经过管道缓冲。

（如维护者需要，我可提供 pnpm --debug/--reporter=append-only 日志或最小复现脚本，但本次只发生一次，触发条件尚未定位，不敢声称确定性复现。）

希望 DSH 侧改进的点（即使挂点是 pnpm）

1. 给 job 快照加活性信号（最关键）。job_list / job_output 的返回里增加 lastOutputAt（最后一条输出时间，最好再加进程树 CPU 增量或“idle since”）。这样 agent 就能执行策略：“运行中 + N 分钟无新输出 → 判定卡死 → job_kill”，而不是无限 wait。目前返回的只有文本 + [status: running]，信息量为零。
2. 连续 wait 超时的护栏。对同一 job 连续多次 wait 超时后（比如第 2 次起），在结果里附加提示：“job 已 X 分钟无新输出，考虑 job_kill 或改为轮询”，或直接由策略层限制最大连续 wait 次数。
3. 工具描述里警告缓冲型管道。pwsh/bash 工具描述建议补充：后台任务里 | Select-Object -Last N、| Out-String 这类“攒到管道关闭才输出”的写法会掩盖活性（有输出也不可见），建议后台任务改用直写文件（> log 2>&1）或不缓冲的输出，这样 liveness 数据也才有意义。
4. 相关讨论：#483（deadlocked agents + 重启丢尾）、#511（后台服务停止响应后页面永久显示“运行中”）、#1158（长工具调用期间 UI 无反馈、结束时内容一次性涌入）。本案例是同一主题下“后台任务子进程挂死 + agent 无活性信号”的新实例——挂掉的是外部工具链（pnpm），但 DSH 目前无法让 agent 感知并止损。

复现提示

非确定性复现路径：Windows + pnpm 11.7.0，后台任务内执行 pnpm exec dsh plugin --profile web add <link:绝对路径>（目标 profile 正被 dsh web 服务占用时可能更容易触发），随后 agent 对 job 使用 job_output(wait: true) 长等待。低概率出现 pnpm 完成写入后不退出。DSH 侧的问题（无活性信号导致 wait 死循环）在任意一个“后台任务挂死”场景下都能稳定观察到，无需 pnpm 复现即可独立讨论。

[boyin111-1]

Acknowledged — aligns with the existing "deadlocked agents / no liveness signal" family; author's analysis is complete, no duplication.

This is a UI-observability / agent-policy gap rather than a profile-manifest bug: a hung background subprocess yields job_output(wait:true) returning only text + [status: running], so the agent cannot distinguish "slow" from "stuck" and re-waits indefinitely. The author already attributed the freeze to pnpm hanging on Windows (pnpm#9530/#9961 family) and confirmed DSH's own pipe draining isn't the classic deadlock. Related discussion cluster: #483, #511, #1158.

Two points worth emphasizing (all consistent with the author's asks):

1. The liveness-signal gap (lastOutputAt / idle-since / CPU delta in job_list/job_output) is a legitimate tool-metadata improvement independent of the pnpm hang — an agent policy "running + N min no new output → job_kill" would self-heal instead of freezing. This is separable from any DSH bug.
2. The buffered-pipe footgun (| Select-Object -Last N, | Out-String) is a genuine operational cause of "no output visible while still alive" — recommending direct log-file writes in the tool description is cheap and effective.

No offline-detectable manifest symptom here (it depends on runtime job state); out of dsh-doctor's scope. No fix/release timing implied.

[ZichengGurrr]

补充一下本机真实复现（Windows 11 + dsh 0.1.0-rc.6，桌面壳/便携版构建场景），两个方向都在这套数据里得到印证：

1. npm 挂起且零输出：便携版构建脚本往 runtime 里 npm install @deepseek-ai/dsh，Windows 上跑了 7 分钟以上，期间 job_output 多次返回 [status: running] 且无任何新输出——agent 分不清慢与卡死，只能反复 wait:true，正是本讨论描述的冻结形态。最终任务自行结束（exit 1），所以这次是"假死"而非永久挂死。

2. stderr 与 $ErrorActionPreference='Stop' 的交互：npm 的 deprecation 警告写 stderr，PowerShell 在 Stop 策略下把 NativeCommandError 当成终止错误，构建在 npm 实际 exit 0 的情况下被中断——这是与 liveness 并列的另一个 Windows 操作坑，值得在工具描述或文档里提醒（原生命令重定向 stderr 或局部放宽 EAP）。

3. 管道缓冲确实加剧"无输出"误判：| Select-Object -Last N 形态下轮询拿不到增量；改成 *> log 直接落盘后，每次轮询都能读到真实进度。日志文件方案成本最低、见效最快。

维护者提的 lastOutputAt / 空闲时长元数据非常期待——有了它，"运行 + N 分钟无新输出 → job_kill"的自愈策略就能落地，代替现在盲等 wait:true 的做法。

[ysyecust]

补一个 macOS 上的样本，形态略不同：子进程没有挂死，而是活着但长期零输出，job_output(wait:true) 同样只回 (no new output) [status: running]，agent 无法区分"慢"和"死"。

环境：dsh ptc preset，模型 qwen3.8-flash-next，macOS arm64，load average 39。

时间线（session-18d94bd5，2026-09-03）：agent 以 run_in_background 启动 CPU whisper --model medium 转写 61 分钟音频；随后 8 次 job_output(wait:true, timeout_ms: 420000–600000) 全部超时、零输出，累计盲等 62 分钟（占整轮 160 分钟的 39%）。第 85 分钟 agent 才自行换 mlx-whisper，6 分钟完成。期间 ps 被沙箱拦（/bin/ps: Operation not permitted），agent 连"进程在不在"都查不到。

最小改动建议：PublicJobSnapshot 已有 startedAt，job_output 的 render 里把状态行扩成 [status: running, elapsed 42m, no output since start]（或 last output 3m ago）。有了这一行，模型的 prompt 里 "do not busy-poll" 那条才有可执行的判据。