Uncaught ENOENT in OutputCollector.spillAll kills the dsh web server; spill roots also grow unbounded (13 GB measured, volume driven to 197 MB free)

[Dewario]

Upstream report — @deepseek-ai/dsh

Channel: deepseek-ai/deepseek-harness has GitHub Issues disabled (the API returns
410 Issues has been disabled in this repository). The project README routes feedback and bug
reports to GitHub Discussions, so this one was posted there, under Q&A.
Packages: @deepseek-ai/dsh 0.1.7-rc.2 observed; crash stack from @deepseek-ai/dsh-subprocess-local 0.1.2-rc.1
Environment: Windows 11, Node v22.17.0
Severity: Critical — one deleted temp dir kills the entire dsh web server and every live session

Title

Uncaught ENOENT in OutputCollector.spillAll terminates the whole dsh web server when its spill dir is deleted mid-session

Observed crash (verbatim)

Error: ENOENT: no such file or directory, open 'C:\Users\Prime\AppData\Local\Temp\dsh-subprocess-Kp72eM\dsh-subprocess-18596-1-8ee8c7f6420e-stdout.log'
    at openSync (node:fs:561:18)
    at OutputCollector.spillAll (file:///C:/Users/Prime/AppData/Local/npm-cache/_npx/1e7f6d9597241db0/node_modules/@deepseek-ai/dsh-subprocess-local/lib/index.js:717:19)
    at OutputCollector.push (file:///C:/Users/Prime/AppData/Local/npm-cache/_npx/1e7f6d9597241db0/node_modules/@deepseek-ai/dsh-subprocess-local/lib/index.js:693:75)
    at Socket.<anonymous> (file:///C:/Users/Prime/AppData/Local/npm-cache/_npx/1e7f6d9597241db0/node_modules/@deepseek-ai/dsh-subprocess-local/lib/index.js:862:14)
    at Socket.emit (node:events:518:28)
    ...
Node.js v22.17.0

The process hosting the web GUI (all sessions) died. The filename's spill counter (-1-) shows this was the server's first spill, ~83 minutes into the run — any subprocess whose output first exceeds the in-memory cap after the dir disappears triggers it.

Root cause

• lib/index.js:648-651 — the spill dir is created once per process via mkdtempSync(join(tmpdir(), "dsh-subprocess-")) and cached in defaultSpillDir. The module imports no mkdir, so it can never be recreated.
• lib/index.js:710-721 — spillAll() calls openSync(this.spillFile, "wx", 384) and writeSync(...) with no error handling, synchronously inside a stream data handler (push() at :693, wired at :862). Any failure escapes as an uncaught exception and takes down the whole server, not just the affected subprocess.
• Nothing in any @deepseek-ai/* package deletes these dirs — a source-wide grep finds only the mkdtemp line, the per-file name template, and dependency pins. So an external %TEMP% cleaner (Storage Sense, AV, manual sweep) removing the live dir mid-session guarantees this crash on the next spill.
• Adjacent observation: stale dsh-subprocess-* dirs are never pruned; six accumulated on this machine over 10 days of normal use.

Measured volume impact (Windows 11, 2026-09-29) — separate from the crash above

The same never-pruned behaviour was measured on a second, larger spill root on the same machine
(%LOCALAPPDATA%\dsh-temp, alongside the %TEMP%\dsh-subprocess-* dirs described above):

Measurement	Value
Directory size	13.03 GB across 41,415 files
Largest single spills	7 files of 444-600 MB, all dated the previous day
Free space on C: at that moment	197 MB (volume: 926 GB used of ~1 TB)
After reclaiming files older than 24 h	37,033 files / 7.75 GB deleted; C: 16.9 GB -> 24.67 GB

Downstream effects while the volume sat at 197 MB — all on the host, none of them inside the
spill code:

• another long-running agent process on the machine failed every write with
  OSError: [Errno 28] No space left on device; its cron persistence, its rotating log handler
  and its gateway loop all broke and retried in a loop;
• the CodeGraph MCP daemon for a neighbouring project began failing keepalives and reconnecting,
  and a full index rebuild could not take its database lock at all (EPERM ... database file is in use) — which is what a full disk looks like from SQLite's side;
• operations that spill large output became the least reliable thing on the box.

One observation recorded but not re-verified, because our local remedy reclaimed the files
before it could be checked: a depth-limited listing showed the same 599.9 MB file name three
times in that tree, which may mean duplicate spills of one object rather than three distinct ones.

What we did locally (not a substitute for upstream pruning)

deploy/dsh-temp-reaper.ps1: reports by default, deletes only files older than a threshold
(default 24 h) inside a directory whose leaf is exactly dsh-temp, skips locked files without
forcing them, prints denominators, appends one line per run; installed as a daily 03:00 task
ahead of the 03:30 reindex so space is reclaimed before anything needs to write.

Ask

1. Prune stale spills on startup and/or on a timer, bounded by age and total size, like any
   other cache.
2. Document the spill roots (%TEMP%\dsh-subprocess-* and %LOCALAPPDATA%\dsh-temp) so an
   operator can bound them without reverse-engineering.
3. Fix the uncaught-ENOENT path described above — that is what turns any external cleanup,
   ours included, into a server-wide crash.

Repro

1. npx @deepseek-ai/dsh web, open a session (the spill dir is created lazily once a spill-capped subprocess spawns).
2. Delete %TEMP%\dsh-subprocess-* while the server runs.
3. Produce any subprocess output exceeding the in-memory collection cap (e.g. a long-running session agent or an MCP child with chatty stdout). The server exits with the stack above.

Suggested fix (applied and verified locally)

Wrap the spill path in try/catch; on failure degrade to the existing tail-only path via discardSpill() (which already sets spillDisabled = true), recreate the dir on ENOENT so later collectors can spill again, and warn once per process:

--- a/lib/index.js (spillAll)
+import { ..., mkdirSync, ... } from "node:fs";
 	spillAll(chunk) {
 		if (this.maxSpillBytes !== void 0 && this.total > this.maxSpillBytes) {
 			this.discardSpill();
 			return;
 		}
-		if (this.spillFd === void 0) {
-			this.spillFile = join(this.spillDir, `dsh-subprocess-${process.pid}-${++spillCounter}-${randomBytes(6).toString("hex")}-${this.label}.log`);
-			this.spillFd = openSync(this.spillFile, "wx", 384);
-			for (const prior of this.chunks) writeSync(this.spillFd, prior);
-		}
-		writeSync(this.spillFd, chunk);
+		try {
+			if (this.spillFd === void 0) {
+				this.spillFile = join(this.spillDir, `dsh-subprocess-${process.pid}-${++spillCounter}-${randomBytes(6).toString("hex")}-${this.label}.log`);
+				this.spillFd = openSync(this.spillFile, "wx", 384);
+				for (const prior of this.chunks) writeSync(this.spillFd, prior);
+			}
+			writeSync(this.spillFd, chunk);
+		} catch (error) {
+			this.discardSpill();
+			if (error?.code === "ENOENT") {
+				try { mkdirSync(this.spillDir, { recursive: true }); } catch {}
+			}
+			if (OutputCollector._spillWarned !== true) {
+				OutputCollector._spillWarned = true;
+				console.warn(`dsh-subprocess-local: output spill to ${this.spillDir} failed (${error?.code ?? error?.message ?? String(error)}); degraded to in-memory tail${error?.code === "ENOENT" ? " and recreated the spill dir" : ""}`);
+			}
+		}
 	}

Optional hardening: prune stale dsh-subprocess-* dirs at startup (they leak forever today), and consider a process-level uncaughtException guard for the web server so one subsystem can't take down every session.

[PerryLink]

⚠️ 你的崩溃违背了本包自己声明的行为——我把两处原文给你

1. 文档写明的处置方式（HEAD = dsh-v0.2.1-alpha.1）

packages/subprocess/subprocess-local/README.md:47：

Spilling is best-effort: when the spill file cannot be opened or appended (the per-process directory removed by a temporary-file cleaner, EACCES, EMFILE, ENOSPC), the collector discards the spill, logs one error through the plugin logger, and keeps collecting the in-memory tail, so the result is truncated with no spill path.

⇒ 关键三点：① ENOENT（目录被清理器删掉）被明确列举为已知情形；② 处置是丢弃 spill + 记一条 error + 继续收内存尾巴；③ 不是让进程退出。

⇒ 所以"spillAll 里的未捕获 ENOENT 打死 web 服务"违背了这份契约——按文档，它应当只损失一条完整输出，而不是整个服务。

2. 文档甚至说明了"为什么不重建目录"

同文件 :157：

A removed spill directory is not recreated — the private per-process directory is created once; after an external cleaner removes it, every later spill in that process degrades to the in-memory tail with an error log until the host restarts. Recreating a fresh random directory on ENOENT is deferred work.

⇒ 也就是说："不重建"是有意的（deferred work），但**"因此崩溃"不是**。⇒ 请把这一点写进报告："不重建目录是已声明的取舍；但未捕获异常导致服务退出不是。" ⇒ 这让你的诉求无法被"那是已知限制"驳回。

3. ⇒ 诉求可以精确成一句

spillAll 的 ENOENT（以及 EACCES/EMFILE/ENOSPC）必须被捕获并按文档降级（记一条 error、继续收内存尾巴）；不得冒泡成未捕获异常导致宿主退出。

建议同时补一句"为什么严重"：进程退出会丢掉所有进行中的会话，而代价本应只是"这次看不到完整输出"——代价与后果完全不成比例。

4. 你的第二个问题（spill 根目录无界增长）请单独提一条

你实测 13 GB、卷只剩 197 MB。⇒ 这与第 1、2 节是两个独立问题（一个是异常处置、一个是清理策略）。⇒ 建议拆开，并补两样：

1. 那些文件属于哪些进程（进程已退出仍需人工清？还是仍在跑）；
2. 是否有启动期清理——若没有，建议加一条"启动时清理超过 N 小时的 per-process spill 目录"。

注意文档对"已完成 spill"的说明：它们被描述为 full-output recovery artifacts，会保留到外部清理 ⇒ 所以"堆积"在设计上是预期的一部分，但**"堆到 13 GB"不是**。⇒ 你的数据（13 GB / 197 MB）正好说明缺少上限或缺少清理——这是可验收的。

5. 版本

你写 0.1.7-rc.2；当前最新是 0.2.1-alpha.1（0.1.7-rc.2 → 0.2.1-alpha.1 共 714 个提交）。⇒ 请确认新版是否仍崩（我核到 :47/:157 两段文档仍是原样，但实现是否补了 catch 需要你实测）。

6. 一条边界

我确认的是**文档声明的处置方式与"ENOENT 属已知情形"**这两点（逐字引用）。未捕获异常的具体位置以你的栈为准——我没有该现场。