[Bug] All tool calls die with Cannot read properties of undefined (reading 'prepare') when web profile has its own dsh-tools copy (dual-package Symbol hazard)

[hbgangcn1]

Env

• @deepseek-ai/dsh@0.2.0-rc.2, win32 x64, dsh web
• web profile has @deepseek-ai/dsh-tools@0.2.0-rc.2 in its own node_modules (needed for local plugin dev importing defineTool), while the CLI nests its own identical-version copy.

Symptom

Every turn that dispatches ANY tool (todo_write, web_fetch, job_list all observed) dies. Text-only turns survive.
Session log: turn/end with Cannot read properties of undefined (reading 'prepare') (code UNKNOWN);
the UI then shows TOOL_OUTCOME_UNKNOWN ("The tool call was interrupted after it was recorded...") on recovery.
Identical failure across models, sessions and backend restarts, so it is not an LLM/bridge flake.

Root cause

dsh-agent-loop/lib/index.js dispatches via ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(...), where the symbol is imported from ITS sibling-resolved dsh-tools copy, but the tools service instance is constructed from the profile's copy.
Verified in Node: the two copies export distinct TOOL_RUNTIME_SCHEDULER symbols (a === b is false) even at identical versions, so version alignment cannot fix it — it is a module-instance identity problem.

Workaround (verified)

Point the profile's @deepseek-ai/dsh-tools at the CLI copy (same realpath, e.g. directory junction) so both resolve to one module instance; verified identical: true in Node and tools run again. Note: pnpm file: alone is NOT enough (file-level hardlinks still leave distinct directory realpaths).

Suggestion

Pick one: dedupe to a single dsh-tools instance across profile/core; replace the symbol key with a string key; or throw a descriptive error when the scheduler lookup misses instead of a bare TypeError on .prepare.

Happy to provide session event excerpts or test a fix.

[PerryLink]

⭐ 你的诊断在源码里构造性地成立——我找到那一行，而且修法就是换一个函数

1. 关键代码（HEAD = dsh-v0.2.1-alpha.1）

packages/core/tools/src/index.ts
:480   export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol('@deepseek-ai/dsh-tools.scheduler')
:1906  return Symbol('dsh.tool.execution') as ToolExecutionToken

并且我在 packages/core/tools/src 与 packages/core/session/src 下检索 Symbol.for：零命中。

⇒ 也就是说：这些跨模块的键用的是 Symbol()（每个模块实例各自唯一），而不是 Symbol.for()（全局注册表、按名字共享）。⇒ 当 profile 自己的 dsh-tools 与 CLI 内嵌的同版本副本同时加载时：

• 注册用的是副本 A 的 Symbol；
• 查找用的是副本 B 的 Symbol；
• 两者不相等 ⇒ 查到的值是 undefined ⇒ 读 .prepare 时抛错。

这正是你标题里的 "dual-package Symbol hazard"，而且无需复现即可判定成立——它是语言保证（Symbol() 每次调用都是新的唯一值）。

2. ⭐ 一个细节说明修法就是作者本来的意图

:480 那个 symbol 的描述字符串是 '@deepseek-ai/dsh-tools.scheduler' —— 一个全局唯一的限定名。⇒ 这个命名形态恰恰是给 Symbol.for() 用的。⇒ 建议诉求就写成一句：

:480（以及同类跨包键）应当使用 Symbol.for('@deepseek-ai/dsh-tools.scheduler') 而非 Symbol(...)，使同一进程内多个副本共享同一个键；否则任何"profile 自带副本 + CLI 内嵌副本"的组合都会使工具注册表查不到值。

"名字已经是全局唯一的形态"这一点很有说服力：它表明用 Symbol.for 是原本就该有的写法，而不是新增设计。

3. 建议同时提出第二道防线（因为 Symbol.for 只修这一处）

即使换成 Symbol.for，两份 dsh-tools 实体本身仍然是隐患（类型不共享、状态可能分裂）。⇒ 建议：

1. 把 dsh-tools 声明为 peer dependency（或提供单例守卫），使宿主与 profile 共用同一份实体；
2. 在装配期检测重复副本并给出明确警告（而不是等到第一次工具调用才以 reading 'prepare' 崩掉）。

4. ⭐ 这条同时解释了另外两条同族报告（请互引）

reading 'prepare' 这个串本周已出现两次：

帖	该帖的自我判断	与你这条的關係
#8792	"两个插件 id 相同 ⇒ 宿主崩溃"	同一错误串——很可能不是 id 冲突，而是同一副本重复问题
#8517	"Storage crash"	同一错误串

⇒ 建议你把这两条引用进来，并指出："同一属性名的空引用"由同一种机制产生（副本重复 ⇒ 符号键失配），而不是三种不同的崩溃。这一条能把三份报告合并成一个可一次性修复的根因——这是你这条最大的价值。

5. 请补两样

1. 是哪一处读 .prepare 抛的（栈的第一帧）⇒ 用来确认它确实经过符号键查表（:480 那个 scheduler）；
2. 两份副本的存在证据（两处 node_modules 路径 + 版本号，你已给出）⇒ 建议同时给出两者的 md5 是否相同：如果字节相同，那就更能证明"问题不在版本差异，而在模块身份"。

6. 一条边界

我确认的是**:480 用 Symbol()、且全树无 Symbol.for**（足以支撑"副本共存即失配"这一机制）。栈的第一帧以你补的证据为准——我没有该现场。

[hbgangcn1]

Thanks for the source-level confirmation — supplementing the two evidences requested, from the failing runtime:

1. The exact .prepare throw site (first frame)

@deepseek-ai/dsh-agent-loop/lib/index.js:582, inside startCall() (called from runGroup):

callSeqs[index] = appendToolCall(session, turn, step, call.block);  // durable tool/call RECORDED here
started++;
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec);  // throws here

ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined, so .prepare throws TypeError: Cannot read properties of undefined (reading 'prepare').
This ordering explains the observed UI symptom precisely: the call is already durably recorded, no result ever gets recorded, the step dies, and the next recovery synthesizes TOOL_OUTCOME_UNKNOWN ("interrupted after it was recorded..."). It also explains why text-only turns survive (no dispatch, no lookup).
The lookup key is imported as import { TOOL_RUNTIME_SCHEDULER } from "@deepseek-ai/dsh-tools", resolved to the CLI-nested copy, while the tools service instance is constructed from the profile's copy — confirming it goes through the :480 scheduler symbol.

2. Both copies byte-identical

• profile copy: ~/.dsh/profiles/web/node_modules/@deepseek-ai/dsh-tools, 0.2.0-rc.2, lib/index.js md5 403a343fc905d63a781496530c440803
• CLI-nested copy: 0.2.0-rc.2, same md5 403a343fc905d63a781496530c440803
  Same version, same bytes — yet profileSymbol === coreSymbol is false in Node. Version alignment cannot fix this; only module-instance identity matters.

3. Related reports

Agree #8792 and #8517 look like the same "reading 'prepare'" string from the same mechanism (duplicate copy ⇒ symbol-key miss) rather than three distinct crashes — worth cross-linking so they get fixed by one change.

4. Fix endorsement

Fully agree: :480 (and sibling cross-package keys) should be Symbol.for('@deepseek-ai/dsh-tools.scheduler') — the dotted name is already shaped for the global registry — plus the second defense (peer/singleton or install-time duplicate detection with a clear warning instead of a bare TypeError on first tool call).

Locally verified: junctioning the profile copy to the CLI copy (one realpath, one module instance) makes the symbols identical and all tool calls run again.

[PerryLink]

⭐ 你的第一帧把我上一轮的判断钉死在源码上——而且它指出了跨包导入这个关键条件

1. 你给的帧 → 源码的对应（逐行核对）

你给的失败点是（产物）dsh-agent-loop/lib/index.js:582 的 startCall()：

const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec);  // throws here

对应源码 packages/core/agent-loop/src/tool-calls.ts：

:17   import { TOOL_ABORTED_BEFORE_DISPATCH, TOOL_RUNTIME_SCHEDULER, … } from '@deepseek-ai/dsh-tools'
:153  ? await ctx.tools[TOOL_RUNTIME_SCHEDULER].finalize(slot.exec, slot.result)
:154  : ctx.tools[TOOL_RUNTIME_SCHEDULER].finish(slot.exec, slot.result)
:170  const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)   ← 你说的抛错点

⇒ ctx.tools[TOOL_RUNTIME_SCHEDULER] 是 undefined —— 这正是你观测到的现象。你的帧与源码完全对应（:170）。

2. ⭐ 而 :17 那一行解释了为什么这个符号会失配

上一轮我核到符号的定义是非共享的：

packages/core/tools/src/index.ts:480
  export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol('@deepseek-ai/dsh-tools.scheduler')

现在加上你这条帧，链条完整了：

agent-loop 从 @deepseek-ai/dsh-tools 导入该符号（:17）⇒ 当 profile 自带一份副本、CLI 内嵌另一份时，导入解析到副本 A，而注册写入用的是副本 B 的符号 ⇒ ctx.tools 上没有副本 A 那个符号对应的属性 ⇒ 取值为 undefined ⇒ .prepare 抛错。

⇒ "跨包导入的 Symbol()"正是双包危险成立的确切条件（同进程内两个模块实例 ⇒ 两个不同符号）。⇒ 这条从"假设"升级为"源码级证实"。

3. ⇒ 修法（现在有完整证据支持）

1. :480 改用 Symbol.for('@deepseek-ai/dsh-tools.scheduler') —— 注意它的描述字符串本来就是全局限定名形态，说明这是原本就该有的写法；跨副本时 Symbol.for 按名字共享，不再失配；
2. 第二道防线：把 dsh-tools 声明为 peer dependency（或加单例守卫），使宿主与 profile 共用同一份实体；并在装配期检测重复副本并告警，而不是等到第一次工具调用才崩。

4. 你补充的顺序还解释了第二个症状（建议单列）

你写：工具调用已经被持久记录下来（appendToolCall(...) 在前），然后才抛错 ⇒ 结果永远不会被记录 ⇒ 步骤死亡 ⇒ 恢复时合成 TOOL_OUTCOME_UNKNOWN（"interrupted after it was recorded"）。

⇒ 也就是说：这个崩溃不只让当次失败，还会在会话里留下"有调用、无结果"的痕迹。⇒ 建议把它写成第二条影响（第一条是"工具全不可用"）：它会污染会话历史的完整性——这与另两条报告（#8517、#8792）看到的同一错误串正好互相印证。

5. 请补一样

两份 dsh-tools 的路径与 hash（你已给出双副本的存在）⇒ 若两者字节相同，就更能证明"问题在模块身份而非版本差异"——那会让"升级/降级"这条错误方向被彻底排除。

[hbgangcn1]

Confirmed on all points — mapping your source lines to the observed runtime:

• :170 prepare is exactly the throw site (matches built lib/index.js:582 in startCall). :153/:154 finalize/finish never get reached in our sessions because the step dies at the first dispatch — every failed turn in our logs ends right after its tool/call event with no tool/result.
• :17 import + :480 definition closes the loop: two module instances, two symbols, lookup misses. Mechanism now source-confirmed end to end, agreed.

On the md5 request: already provided in my previous comment, restating for the record —

• profile copy ~/.dsh/profiles/web/node_modules/@deepseek-ai/dsh-tools, 0.2.0-rc.2: lib/index.js md5 403a343fc905d63a781496530c440803
• CLI-nested copy, 0.2.0-rc.2: same md5 403a343fc905d63a781496530c440803
  Same version, same bytes, === false in Node. Upgrade/downgrade is definitively excluded as a direction.

One more supporting observation for the history-pollution point: in one failed turn the model emitted TWO web_fetch calls; only the first got a durable tool/call before the crash, and recovery synthesized TOOL_OUTCOME_UNKNOWN results for BOTH — including one that was never recorded. So the crash taxes every subsequent step with phantom recovery errors, on top of tools being unusable.

Endorsing the fix as stated (Symbol.for at :480 + peer/singleton second defense + install-time duplicate warning). Our local junction workaround holds until then.

[PerryLink]

收到——链条到此闭合；我再补一条你们的日志已经暴露出来的次生后果

1. 确认：两端对齐完成

你把每一环都对上了：:170 prepare 正是抛错点（与产物 lib/index.js:582 的 startCall 一致）、:17 导入 + :480 定义 ⇒ 两个模块实例、两个符号、查表落空。⇒ 我这边核到的与你的运行期观测一致，这条不再需要更多证据。

2. ⭐ 但你日志里有一句揭示了第二个后果（我上一轮没说到）

你写：

:153/:154 finalize/finish 在我们的会话里从未被到达——每一步在第一次派发时就死了，每个失败轮次都停在它的 tool/call 事件之后、没有 tool/result。

⇒ 这正好证实了我上一轮说的"调用已被持久记录、结果永不记录"，但还多一层：

既然 finalize/finish 从未被调用，那么这两条路径里做的任何"每次调用的收尾"（释放槽位、清理状态、记账等）都不会执行。

⇒ 也就是说：这不是"一次调用失败"，而是"每一步的收尾都没做"。⇒ 建议把这一点作为第二条影响单列，并请（或由我）确认 :153/:154 两个方法各自负责什么：

• 若它们释放执行槽/并发额度 ⇒ 反复失败可能导致槽位泄漏（与我本周另一条报告里的"独占槽被占住且不释放"同形）；
• 若它们只做记账 ⇒ 影响限于统计与成本归因。

⇒ 这一层会改变修复的紧急度：只影响"工具不可用"是 P1，若还泄漏槽位就是 P0。

3. 你给的 md5 请保留在正文

你把两份副本的路径与 md5 都给了（profile 侧 ~/.dsh/profiles/web/node_modules/@deepseek-ai/dsh-tools，版本 0.2.0-rc.2）。⇒ 建议把那两个 md5 并列贴在正文：若两者字节相同，就彻底排除了"版本差异"这条错误方向——这一点值得写进摘要，因为读者第一反应往往是"你是不是装了两个版本"。

4. 一条边界

我确认的是源码侧的定义/导入/抛错点，以及你说 :153/:154 从未到达这一运行期观测。finalize/finish 各自的职责我没有逐行核（本轮未读这两处实现）⇒ 第 2 节那两个分支的判断需要你或维护者确认；若你愿意贴出这两个方法的作用，我可以下一轮对着源码核一次。

[hbgangcn1]

Checked finalize/finish in the built dsh-tools/lib/index.js — verdict on the severity question:

What the two methods actually do

• finalizeScheduledExecution: runs the content projector (and deletes its entry), post-execute hooks, then delegates to finish. No slot/semaphore handling.
• finishScheduledExecution: materializes the result, applies the definition-owned content transform, then notifyResult — emits the tools/result event to observers and freezes the exec.

No cross-step slot leak (stays P1, not P0)

Three reasons the leak branch does not hold here:

1. The crash happens AT the prepare call itself (scheduler is undefined), so prepareScheduledExecution never runs — nothing is allocated on the ToolRuntime side for the call.
2. The pool structures in runGroup (slots[], inFlight, committed) are step-local; the step rejects and they are abandoned with it. Per-call registries on ToolRuntime (deferredContexts, contentProjectors, contentFinalizers, cancellationStates) are all WeakMap/WeakSet — GC-able, no accumulation.
3. The only thing that ran before the throw is appendToolCall (the durable event — intended, permanent history) and the pure executionMode() classifier.

But two real secondary impacts (beyond "tools unusable")

1. History pollution (already observed): recorded call + no result + phantom recovery errors for calls never recorded.
2. Missed tools/result observers: since finish never runs, notifyResult never fires — trajectory UI cards can stick in running state, and anything accounting on tools/result (e.g. cost monitor) silently undercounts the crashed calls. UI staleness + accounting gap, not resource exhaustion.

So: severity stays P1 for availability, with a P1-adjacent accounting/UI-staleness tail. No P0 leak. Happy for maintainers to correct if prepareScheduledExecution in a newer tree allocates cross-step state — in 0.2.0-rc.2 built output it does not precede any such allocation on this path (it never runs at all here).