[Bug][tool-fs][0.2.1-alpha.2] write/edit result-card diff runs untimed on the Host thread; an 8,000-line overwrite freezes every session for ~8 s

[heaven999b]

中文摘要：write/edit 的结果卡片在 presentationMeta 里于主线程同步调用 jsdiff structuredPatch，未设 timeout；Myers diff 为 O(N·D)，8000 行覆盖写会冻结整个宿主约 8 s。修复为新增经校验的 diffTimeoutMs 配置（默认 100 ms，与 workspace-changes 对齐），超时则不产出 hunk，write 回退到按参数生成的整文件卡片、edit 回退到通用卡片；附回归测试，修复后同一场景主线程最长停顿 49 ms。

Summary

After a successful write or edit, the tool computes the result card's hunks in output.presentationMeta by calling jsdiff structuredPatch synchronously on the Host thread, with no timeout or maxEditLength. Myers diff costs O(N·D), so overwriting or rewriting a large file with mostly different content is near-quadratic. The write itself finishes in milliseconds, but the card diff then blocks the event loop: every session's streaming, timers, the API server, and the WebSocket mux stall.

The sibling package workspace-changes already passes timeout to the same function and degrades to a whole-file replacement when it expires.

Environment

• dsh 0.2.1-alpha.2, master d743267388
• Source checkout, pnpm install --frozen-lockfile
• macOS 14.4 (Darwin 23.4.0), Apple Silicon (8 cores, 8 GB), Node v24.11.1
• Reproduces in a new session
• Measured while the machine ran about 10 parallel test workloads; absolute times are inflated, ratios are reliable

Reproduction

Mount fs-local + tool-fs, create a file of N JSON-ish lines, then write it with N different lines (a regenerated data file, a reformatted source file, a translated catalog):

Lines overwritten	master: event-loop block (earlier run)	branch: write call total / longest stall
1,000	0.19 s	not measured
2,000	not measured	300 ms / 52 ms
4,000	3.2 s	297 ms / 37 ms
8,000	8.4–14.9 s	365 ms / 49 ms
edit replace_all touching all 8,000 lines	not measured	718 ms total; a 50 ms timer fired at 79 ms

The master column comes from an earlier run of the same repro on the same machine under similar load; growth is near-quadratic in the line count. On master a timer scheduled during the call fires only after the diff finishes. The persisted meta for a full overwrite was about 2.4× the written bytes on master and is 0 KiB on the branch (the timed-out comparison yields no hunks).

Root cause

• Untimed comparison: packages/fs/tool-fs/src/diff.ts#L36
• Callers, run synchronously by the tool registry after execute: write.ts#L102-L108, edit.ts#L112-L115
• Same function with a budget in workspace-changes: packages/deliverables/workspace-changes/src/compare.ts#L41

Fix

Branch: heaven999b/deepseek-harness@fix/tool-fs-diff-timeout (compare with master) (one commit, cf714dee7d, based on d743267388; 11 files, +139/−25)

• New validated config field diffTimeoutMs (default 100, the same name and default as workspace-changes), rejected at load unless a positive integer.
• computeHunkDiffs(path, before, after, timeoutMs) passes timeout to structuredPatch; an expired comparison returns no hunks.
• No presenter change is needed: write already falls back to the argument-derived whole-file card when meta.diffs is empty (as for creates), and edit already falls back to the generic card. The client diff-card model behaves the same way. The write/edit operation itself is never affected.
• README (en/zh) documents the field and clarifies that it bounds only the card diff, not the tool call; the translation-pairing record and the generated docs/config-catalog.md (en/zh) are updated.

A targeted edit has a tiny edit distance and finishes far below 100 ms, so normal cards are unchanged.

Verification

• New tests (fail on master, pass on the branch):
  • degrades to no hunks when the comparison exceeds the timeout — a 4,000-line rewrite with a 1 ms budget returns [] within 1 s (on master the untimed comparison runs to completion and returns hunks).
  • write overwrite: a timed-out diff leaves empty meta and presentResult falls back to the whole-file card
  • edit replace_all: a timed-out diff leaves empty meta and presentResult falls back to the generic card
  • config validation rejects diffTimeoutMs: 0 and 2.5
• Existing exact-hunk tests pass unchanged (with an explicit ample budget).
• Re-run on d743267388. vitest run packages/fs/tool-fs/tests --coverage --coverage.include='packages/fs/tool-fs/src/**/*.ts': 221 tests pass; every src file at 100% statements/branches/functions/lines.
• Against master's sources, the new write and edit tests take about 2.5 s each, almost all of it the untimed comparison of a 4,000-line rewrite; with the fix they finish in about 20 ms.
• tsc -b packages/fs/tool-fs/tsconfig.json and tsc -b tsconfig.host.json (includes the specs): clean. gen-config-catalog --check, verify-translation-pairing, verify-md-wrap, staged oxlint and git diff --check: pass.
• The same repro (write 2k/4k/8k lines, edit replace_all 8k lines) produced the "branch" column above.
• meta is UI presentation only and normal edits are unaffected, so no keyless snapshot was re-recorded.

Follow-up not included: when a large diff does complete within budget (many scattered small changes), meta can still be large and is persisted in the session log. tool-fs-search bounds its meta with searchMetaMaxBytes (64 KiB); an equivalent byte cap for write/edit diffs would be a separate change.

Related

• Searched Discussions for structuredPatch, write diff slow, edit large file freeze, event loop blocked: no existing report.
• 提议：FileDiff 携带 hunk 起始行号（oldStart/newStart），让 UI 能显示真实行号 #8212 (FileDiff hunk start lines) touches the same diff projection but a different concern.
• Same class of problem: sessionQuery.readEvent clones the whole log per call: a documented bounded read costs O(log length), stalling the Host (~257 s on a 4374-event session) #7434, [Bug] sessionQuery.readEvent deep-clones the entire session on every call — reading one event is O(session size), and it locks the whole Host event loop #7356, [Bug] Host enters a CPU-bound loop and blocks the event loop when a turn starts in a large session (~700k+ tokens) #7115, [Bug] Responses tool argument streaming saturates CPU and blocks the event loop (pi-ai 0.85.1; runnable repro) #6747.

[PerryLink]

机制确凿，修复设计也对。但先说清一件事：这条在仓库里是明文设计，不是漏了参数 —— 这决定了它是 bugfix 还是设计变更，也决定 PR 该怎么写。

1. ⚠️ 先看这句：tool-fs 明确声明"没有超时面"

packages/fs/tool-fs/README.md:250：

No timeout surface — read/write/edit take no timeout argument and declare no timeout budget; cancellation rides exec.signal only

⇒ 所以加 diffTimeoutMs 是一条需要同时改 README 的设计变更，不是"补上一个漏掉的参数"。报告里先交代这一点，能省掉一轮"这是 by design"的往返。

2. 根因：computeHunkDiffs 没有预算

packages/fs/tool-fs/src/diff.ts:35-36：

export function computeHunkDiffs(path: string, before: string, after: string): FileDiff[] {
  const patch = structuredPatch('', '', before, after, undefined, undefined, { context: DIFF_CONTEXT })

没有 timeout，也没有 maxEditLength；DIFF_CONTEXT = 3（:12）。你引的 diff.ts#L36 精确命中。

它确实压在宿主主线程上 —— packages/core/tools/src/index.ts:1851-1858 在 createSuccessResult 里同步调用：

if (tool.output.presentationMeta !== undefined) { … projected = tool.output.presentationMeta(exec.arguments, value) … }

调用点两个：write.ts:103-110（你写 #L102-L108，实为 :103-110）与 edit.ts:113-117（你写 #L112-L115，实为 :113-117）。computeHunkDiffs 全仓只有这两个调用点。

3. ⭐ 最强对照：同一个函数在别处有预算，而且命名已存在

packages/deliverables/workspace-changes/src/compare.ts:41（你引的 #L41 精确命中）：

structuredPatch('', '', oldText, newText, undefined, undefined, { context: CONTEXT_LINES, timeout: timeoutMs })

配置面 packages/deliverables/workspace-changes/src/index.ts:56 → diffTimeoutMs: z.number().default(100)，校验在 :100（Number.isSafeInteger(value) && value >= 1）。

⇒ 仓库内部已有先例与命名，所以新字段沿用 diffTimeoutMs / 默认 100 是站得住的 —— 这条建议写进报告，它把"我建议加个超时"变成"照隔壁的写法补齐"。

4. 你方案的前提风险：我已核实不存在

你担心的"若 diff 版本不带 timeout，patch.hunks 求值会 TypeError"——

• pnpm-lock.yaml:18968 锁 diff@9.0.0
• 其 libesm/types.d.ts:30-33 原文："A number of milliseconds after which the diffing algorithm will abort and return undefined."；AbortableDiffOptions = TimeoutOption | MaxEditLengthOption
• libesm/patch/create.js:126-131 → function diffLinesResultToPatch(diff) { if (!diff) return; … } ⇒ 超时返回 undefined 时根本不读 .hunks

⇒ 方案成立，你写的 if (patch === undefined) return [] 是正确且必要的。

5. 回退链已存在，不需要改 presenter

• write.ts:148-149 → const diffs = diffsFromMeta(result.meta) ?? [{ path: …, oldText: null, newText: args.content }]
• edit.ts:164-165 → const diffs = diffsFromMeta(result.meta); if (diffs === undefined) return undefined
• diffsFromMeta（diff.ts:76-83）把空数组判为 undefined ⇒ 「超时 → 空 hunks」会自动落到整文件卡片 / generic 卡片

⇒ 你说明里的这一点准确，不用额外接线。

6. 一处值得点明的语义代价

workspace-changes 超时产出的是「整文件替换 + coarse: true」（types.ts:70），而 computeHunkDiffs 超时只能产出空 —— 空与"文件内容相同"不可区分。目前靠 write 的 meta.operation 与 edit 的 diffsFromMeta 回退兜住，但如果将来有人想区分，需要额外标志位。建议在报告里主动披露这一点，比被 reviewer 问出来好。

7. 顺带（你说的 follow-up 属实）

meta 会随会话日志持久化，而 tool-fs-search 有 SEARCH_META_MAX_BYTES = 65_536（tool-fs-search/src/search-core.ts:65，配置项 searchMetaMaxBytes 见 index.ts:103）—— write/edit 没有等价的字节上限。这条可以单列为第二个诉求。

8. 版本与一条边界

• 你的引用三处全对（diff.ts:36、compare.ts:41 精确；write.ts/edit.ts 行号轻微偏移，内容都在）
• 我复核了 git rev-list --count d743267388..origin/master = 0 ⇒ 你标的就是当前 origin/master，不存在"先升级再复现"
• ⚠️ 你给的耗时数字（0.19 s / 3.2 s / 8.4–14.9 s）我无法在你机器外复核，建议在报告里标为"本机实测"。机制（Myers 的 O(N·D) 在主线程同步跑）完全成立，结论不依赖那些数字

9. 用户侧 workaround（今天可用）

• 超大文件 / 全量重写，改用 bash / pwsh 侧生成（redirect、Set-Content），避开 write/edit 卡片的 diff
• 或分批小步 edit（编辑距离小则远低于预算）