DSH 0.1.2-rc.1（Windows）发消息即失败：Cannot read properties of undefined (reading 'find')——会话持久化 ENOENT（0.1.1-rc.2 正常）

[jiuweifanghua]

一、现象

Web 界面发送任意消息后约 200ms，agent 回合即失败，界面显示：

本轮运行失败 Cannot read properties of undefined (reading 'find')  UNKNOWN

• Web UI 完整可加载（输入框、发送按钮、侧栏均正常），仅 agent 对话必崩；
• 会话存储中记录的 turn/end error：message = "Cannot read properties of undefined (reading 'find')"，code = "UNKNOWN"；
• 0.1.1-rc.2 同一套配置完全正常，升级 0.1.2-rc.1 后必现、每次必现、与消息内容无关。

二、环境

• 操作系统：Windows
• DSH：@deepseek-ai/dsh 0.1.2-rc.1（npm 当前最新即此版，无更新的 rc/stable）
• 启动：dsh --profile web，DSH_HOME 为自定义数据目录（非系统默认 ~/.dsh）
• 依赖安装：pnpm（nodeLinker: hoisted），会话存储为 JSONL + zstd 压缩（session.jsonl.zstd）

三、复现步骤

1. 安装 0.1.2-rc.1 并启动 web profile（首次启动控制台即出现大量 ENOENT 异常输出）；
2. 打开 Web UI，任意输入一条消息发送；
3. 约 200ms 后回合失败，提示 Cannot read properties of undefined (reading 'find')；
4. 重复必现。

最小化复现：启动清单缩至仅官方平台层（@deepseek-ai/dsh-base + @deepseek-ai/dsh-web-app，零第三方插件），并切换官方内置 ptc 预设——同样复现。

四、完整排查与排除项（证明非插件 / 非用户配置 / 非路径问题）

#	排除项	隔离做法	结果
1	第三方插件	启动清单缩至仅官方平台层	仍复现
2	Agent 预设	官方内置 ptc 与自定义 ptc-cordis 对比	均复现
3	全局 AGENTS.md（超大指令文件）	临时移走该文件	仍复现
4	顶层 patch 覆盖（cordis.patch.yml 中 agent-instructions maxBytes:262144 等）	移除对应覆盖重启	仍复现
5	profile 中曾显式添加的平台包依赖/副本	全部移除、恢复官方依赖形态重装	仍复现
6	会话存储路径指向错误（怀疑"非默认安装目录"导致）	核查代码 resolve(config.root) 与全部报错路径	路径全部正确指向 DSH_HOME/sessions，与默认/全局路径无关
7	平台版本	同一配置切回 0.1.1-rc.2	可正常对话

五、后台监管证据（node --inspect + 全异常断点，精确抓取）

用 node --inspect 启动 + CDP Debugger.setPauseOnExceptions({state:'all'}) 抓取进程内全部异常：

1. 实例启动即产生 31+ 个「未处理 ENOENT 拒绝（promiseRejection）」，全部来自会话持久化层对会话文件的存在性探测，路径形如：

   <DSH_HOME>/sessions/<工作目录URL编码>/session-<uuid>.jsonl.zstd   （文件不存在）
   

2. 发消息后，agent 回合加载会话走同一条链路失败，随后回合以 error 结束（UI 展示为 reading 'find'）；
3. 抓到的未处理拒绝调用链（异步栈）：

   JsonlSessionPersistence.exists                   dsh-session-persistence-jsonl/lib/index.js（≈1500 行）
   JsonlSessionPersistence.findLog                  （≈1394 行）
   JsonlSessionPersistence.readStoredRevision       （≈900 行）
   PersistenceCoordinator.isPreparedSourceCurrent   dsh-session-persistence/lib/index.js（≈1223 行）
   

六、代码级定位

agent 回合加载会话
  → dsh-session-persistence        isPreparedSourceCurrent()
  → dsh-session-persistence-jsonl  readStoredRevision() → findLog() → exists()
  → exists() 的 Windows 分支（assertLogParentAllowsAbsence）
      对"文件不存在"场景产生未处理 ENOENT 拒绝
  → 会话加载失败 → dsh-agent-loop 捕获 → turn/end error（code: UNKNOWN）→ UI 展示 find

源码审读要点：

• exists() 实现本意：open 抛 ENOENT 时吞掉并返回 false（catch → isENOENT → return false）；
• 实测却产生未处理 ENOENT 拒绝，疑点：
  a) 存在未走 exists() 的 fire-and-forget 探测调用（未 await / await 链漏捕）；
  b) Windows 分支 assertLogParentAllowsAbsence() 内 stat(父目录) 在特定场景（父路径为文件值/竞态/编码目录）抛出的 ENOENT/ENOTDIR 未被外层捕获；
  c) 0.1.1-rc.2 同目录结构、同历史数据完全正常——指向 rc.1 该模块回归。

七、第二现场（疑与 #六 同源，请一并核查）

rc.1 平台包集合未包含 0.1.1 时代的 client 包：@deepseek-ai/dsh-client-runtime、dsh-client-store、dsh-host-apiproxy（疑改名/合并）。部分面向旧 client API 的第三方插件 client 端在 rc.1 下报：

client-modules: require("@deepseek-ai/dsh-client-runtime/client") missed the module table
  — not a platform seed word, not a materialized module, and no registered package factory

UI 控制台另有：TypeError: nodes is not iterable at firstUserText、Cannot read properties of undefined (reading 'legacy')（slot conversation.composer.dock）、slots 服务不可用、多个资源 404。若 rc.1 对 client 运行时改名/合并，请评估向后兼容。

七之二、补充验证：全新空数据（无历史会话）同样复现

将全部历史会话数据目录隔离（改名保留）后启动 0.1.2-rc.1：

• 启动期 ENOENT 风暴消失（0 次）——说明 ENOENT 仅是扫描历史数据的附带噪音，非崩溃主因；
• 发消息仍 200ms 失败（reading find）——崩溃在全新空数据环境同样复现。

→ 与历史会话数据、升级遗留均无关；用官方全新环境即可复现。

八、期望

1. 确认是否为 0.1.2-rc.1 在 Windows 的会话持久化回归，以及是否与历史会话数据/路径布局相关；
2. 请求 rc.2/stable 修复：存在性探测静默处理 ENOENT；会话加载容忍历史数据布局；
3. 评估 rc.1 client 运行时改名的向后兼容；

[argszero]

Source-level follow-up on your sections 五/六 (the ENOENT theory), verified against both dsh-v0.1.2-rc.1 and current master (d347e70390) — I think the persistence-ENOENT thread is a red herring, and your own 七之二 experiment already proves it:

1. The exists() path you suspect cannot produce an unhandled ENOENT. The function (packages/session/session-persistence-jsonl/src/index.ts:1350 on master, :971 in rc.1 — byte-identical between the two) catches ENOENT from open() and returns false. The Windows branch calls assertLogParentAllowsAbsence(path) (:1374), which stats the parent and — critically — catches ENOENT from that stat too (catch (error) { if (isENOENT(error)) return }). It only rethrows a deliberately constructed ENOTDIR for a file-valued parent. So there is no code path where a missing parent/missing file escapes as an ENOENT rejection.
2. Every caller awaits exists(). I checked all call sites in both rc.1 (8 sites) and master (1 site): each is await this.exists(...) inside a method that is itself awaited up the chain. There is no fire-and-forget probe (your hypothesis a), and the stat-ENOENT you worried about in hypothesis (b) is swallowed by the inner catch.
3. Your own 七之二 result already says this: with an empty data dir the ENOENT storm drops to zero, yet the 200 ms reading 'find' failure reproduces. The ENOENT noise and the crash are therefore independent — the noise is a startup-scan artifact (probing absent sessions, harmless), and chasing it will not find the turn failure.

So the actionable crash is the reading 'find' TypeError itself, which by your elimination matrix is: platform-layer-only, any preset, any message, fresh empty store, Windows, 0.1.2-rc.1 (0.1.1-rc.2 fine). That signature points at the live turn/request path, not the persistence read path — the two things that changed between those trains in that neighborhood are agent-loop and session event handling.

One important caveat for your further tracing: the functions you cited from the lib stack (readStoredRevision, PersistenceCoordinator.isPreparedSourceCurrent) are rc.1-era and no longer exist on current master — the JSONL backend's public surface is now readStoredLog(path, expectedId, signal) and session-persistence was reorganized (coordinator.ts split into handle.ts/revision.ts/storage-contract.ts, plus the format-v2/v3 migration work). If you can, the single highest-value experiment is to run your minimal repro (official platform layer + ptc, empty store) against 0.1.3-alpha.1 / current master — if the 200 ms reading 'find' is gone there, the regression was already fixed in the rewrite and the remaining work is just release-note archaeology; if it reproduces, you have a current-tree bug with a much smaller search space than diffing rc.1 internals.

For the current-tree case, the fastest locus finder: run with NODE_OPTIONS=--trace-uncaught (or keep your CDP pause-on-exception but filter to after send, not startup) and capture the actual .find( call site on the undefined receiver — the persisted turn/end error only keeps the message, not the stack, so the in-process trace is the only way to see which module's .find is the receiver.

[libxing]

同样问题，回退 0.1.1-rc.2 了

[argszero]

@libxing 感谢确认——现在这个报告有 2 个 Windows 用户 + OP 的零插件/全新空数据最小复现，可以定性为 rc.1 窗口的 core 回归（不是插件偏斜、不是历史数据、不是路径布局——OP 的三/七之二已经把这三条都排除了）。这跟隔壁 #5860/#5864 那些最终归到插件/版本偏斜的报告不同，#5802 是干净的 core 复现，值得维护者按 core bug 对待。

补一个缩小到具体抛点的建议：turn/end error 只记录了 message + code UNKNOWN，没有堆栈——"reading 'find'" 的具体调用点还不知道。OP 的 node --inspect 实验（五）抓的是启动期 ENOENT 噪音，真正的 .find 抛点发生在发消息后的回合内，被回合机制捕获后只留了 message。要拿到堆栈：

1. 用零插件最小 profile 启动，等启动噪音 settle 后再开 Debugger.setPauseOnExceptions({state:'all'})，然后发消息——这样断点只会落在回合内的真异常上；
2. 或者看 turn/end error 对象有没有 cause 链（日志里 error 若带 cause 会比 UI 展示的 message 深一层）；
3. 顺带一个高价值数据点：在 0.1.3-alpha.1（当前 master 线）上跑同一个最小复现——若已修，说明 rc.1 的修复已在上游；若仍在，维护者拿到的是一个当前线可复现的 core bug。

如果拿到堆栈贴上来，我可以直接按源把抛点找出来（rc.1 窗口的改动面：APIProxy→Remote refactor、Session.events 移除、session-prep 路径都可能是 .find 的宿主）。

[jiuweifanghua]

结论

不是 core 回归。 崩溃元凶 = 第三方插件 @dsh-external/dsh-mode-boost（GitHub: yjh051108/dsh-mode-boost，v0.1.0，最后提交 2026-08-15，未适配 rc.1）。

崩溃点（完整调用栈，按官方建议的"settle 后开断点"方法抓到）

TypeError: Cannot read properties of undefined (reading 'find')
  at Object.<anonymous> (node_modules/@dsh-external/dsh-mode-boost/lib/index.js:88:37)
       const firstMsg = session.events.find((e) => e.type === 'user/message')
  at async Proxy.assemble (npm_cache/@deepseek-ai/dsh-system-prompt/lib/index.js:342:23)

技术原因

• dsh-mode-boost hook 平台 system-prompt/assemble 事件（系统提示词组装）做任务感知模式路由；
• 其 lib/index.js:88 使用 session.events API——该 API 在 0.1.2-rc.1 中被移除（Session.events 移除，恰是 rc.1 改动面之一）；
• rc.1 下 session.events = undefined → .find 崩溃 → 每次 agent 回合 200ms 内失败；
• 0.1.1-rc.2 该 API 存在 → 正常；作者自 2026-08-15 后未更新 → 未适配 rc.1。

为何此前误判为 core 回归

• 该插件通过用户 profile 的 cordis.patch.yml insert 常驻激活（不在 bundles 清单内）；
• 此前"最小 profile（仅平台 bundle）"测试只裁剪了 bundles，未排除 insert 激活的 mode-boost → 误以为零插件仍复现；
• 官方建议的"等待启动噪音 settle 后再开 Debugger.setPauseOnExceptions + 发消息"方法成功抓到真实抛点。

修复与影响

• 禁用 dsh-mode-boost（注释其 insert）后对话完全恢复（实测 agent 正常回复）；
• 建议：官方在 rc.2 说明 Session.events 等 breaking change，供插件作者适配；或将 dsh-mode-boost 情况反馈其作者更新。

[mephistobaal]

macOS · 纯官方 core(零第三方插件)—— 这是核心 bug,不是插件适配问题
macOS · pure official core (zero third-party plugins) — this is a core bug, not a plugin-adaptation issue

环境 / Env:macOS · @deepseek-ai/dsh@0.1.2-rc.1(npm latest)· web profile(nodeLinker: hoisted,launchd)· 无任何第三方插件 / no third-party plugins.

---

复现 / Repro(全新 profile)

1. 新建一个会话 → 发送一条消息 → 约 200ms 后回合失败:
   Create a new session → send a message → after ~200ms the turn fails:
   Cannot read properties of undefined (reading 'find')(code UNKNOWN)
2. 旧会话能正常打开、对话;只有新建会话必崩。
   Old sessions converse fine; only brand-new sessions crash.

---

我验证过什么 / What I verified(排除插件背锅)

• 把 bundles 精简成纯 core(dsh-base + dsh-web-app)、卸掉全部第三方插件 → 仍然复现。
  核心崩溃不在 dsh-mode-boost 或任何插件,而在 core 本身。
  Removed all third-party plugins → still reproduces. Crash comes from core, not from dsh-mode-boost or any plugin.
• 核心崩溃点:client.js 在第渲染时对 undefined 的数组调 .find()
  (state.turnProcesses.find,以及 railItems.find / loaded.find)。
  Core crash site: client.js calls .find() on an undefined array at render time
  (state.turnProcesses.find, also railItems.find / loaded.find).
• 新会话对象不完整:只有 ~4 个字段(title/imageLimits/todos/subagentModelSelectionPolicy,全为空),
  而正常会话有几十个字段。很可能就是你在 Windows 上见到的会话持久化 ENOENT——
  存储层没能水合(rehydrate)新会话,于是渲染层只能对 undefined 调 .find。
  Fresh sessions come back incomplete: only ~4 fields (all empty) vs dozens in a normal session.
  Likely the same session-persistence ENOENT you saw on Windows — the store fails to
  hydrate the new session, so the renderer hits .find on undefined.
• 钉版本对照(同机同环境):回到 0.1.1-rc.2 → 新会话正常;换 0.1.2-rc.1 → 崩。
  版本是唯一变量。
  Pin control (same machine & env): back to 0.1.1-rc.2 → fine; 0.1.2-rc.1 → crash. Version is the only variable.
• 与 x-opencode-session 头无关 —— 那是 Claude-Code 侧设置,DSH 不涉及;而且你的 Windows 复现并没有这个头。
  Unrelated to x-opencode-session headers — Claude-Code-side only; your Windows repro has no such header.

---

npm 发布状态(全是 prerelease,无正式版)/ Release status

• latest = 0.1.2-rc.1(2026-09-03)→ 坏 / broken
• 0.1.3-alpha.2 / alpha.1 → 依赖(@deepseek-ai/dsh-hooks-codex)未发布全,装不上 / deps not fully published, cannot install
• 0.1.1-rc.2(2026-08-21)→ 当前唯一能正常对话的版本 / the only release that converses normally

---

影响与请求 / Impact & ask

影响:latest 上所有新对话都被阻断。请把它当作**核心回归(core regression)**处理,而不是某个插件的适配问题——很高兴提供那份残缺(4 字段)的会话 JSON,如果你需要定位持久化/水合路径的话。
Impact: blocks all new conversations on latest. Please treat this as a core regression, not a plugin-adaptation issue. Happy to attach the incomplete (4-field) session JSON if it helps isolate the persistence/hydration path.