[Bug] [0.1.6-alpha.2]Cannot read properties of undefined (reading 'prepare') on every tool call in web profile — dsh-tools Symbol identity mismatch

[ChenwxJay]

Summary

In the web profile (dsh web), every assistant tool call fails before dispatch with:

TypeError: Cannot read properties of undefined (reading 'prepare')

The error fires immediately after the tool/call event is recorded and before any tool executes. It is model/provider-agnostic — reproduced identically with deepseek-official (native adapter) and glm-5.1-zhipu (via llm-proxy). The cli profile does not reproduce.

Side effect: the failed turn leaves a dangling tool_use block with no tool_result, which the DeepSeek Messages serializer then rejects on the next turn ("tool calls need immediate results" — packages/llm/llm-deepseek/src/protocols/messages/serialize.ts:117), effectively bricking the session.

Reproduction

1. Start a stock web profile on a clean 0.1.6-alpha.2 checkout (no home-layer cordis.patch.yml remount of @deepseek-ai/dsh-tools):

   pnpm dsh web --no-open

2. In the web UI, send a greeting such as "你好啊" (this triggers the built-in hello-world skill → the model emits a skill tool call).

3. The turn fails with Cannot read properties of undefined (reading 'prepare'). The skill never loads.

Any tool call triggers it, not only the skill tool.

Environment

• DSH: @deepseek-ai/dsh-root 0.1.6-alpha.2 (release, clean git)
• OS: Windows 11
• Node: v22 (tsx/esm loader)
• Profile: web reproduces; cli does not
• Models tested: deepseek-official native adapter; glm-5.1-zhipu via llm-proxy — both fail identically (so the bug is in the tool-scheduling layer, not model-specific)

Root cause

@deepseek-ai/dsh-tools is loaded as two independent module copies in the web profile. TOOL_RUNTIME_SCHEDULER is declared with Symbol():

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

Symbol(description) creates a new unique symbol on every call — the description is only a label, not identity. Each loaded copy of the module therefore holds a different TOOL_RUNTIME_SCHEDULER instance that merely shares a description.

• The copy that constructs the ToolRuntime service instance hangs the scheduler object on its symbol:
  ctx.tools[<symbol-A>] = { prepare, dispatch, finalize, finish, ... }
• The copy imported by agent-loop reads with its own symbol: ctx.tools[<symbol-B>]
• Since symbol-A !== symbol-B, the lookup returns undefined, and undefined.prepare(...) throws at:

// packages/core/agent-loop/src/tool-calls.ts:170  (function startCall)
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)

Evidence (diagnostic instrumentation)

I wrapped the throwing call to introspect ctx.tools at the failure point:

{
  "toolCallName": "skill",
  "message": "Cannot read properties of undefined (reading 'prepare')",
  "ctxToolsCtor": "ToolRuntime",
  "hasSchedulerSymbol": false,
  "schedulerType": "undefined",
  "schedulerKeys": ["Symbol(cordis.tracker)", "Symbol(@deepseek-ai/dsh-tools.scheduler)"]
}

Key findings:

• ctxToolsCtor: "ToolRuntime" — the object is the real ToolRuntime service instance (not a facade/proxy).
• schedulerKeys contains Symbol(@deepseek-ai/dsh-tools.scheduler) — a scheduler-keyed symbol is present as an own property of ctx.tools.
• Yet hasSchedulerSymbol (TOOL_RUNTIME_SCHEDULER in ctx.tools) is false and ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined.

An own-property symbol with the right description but failing in against the imported constant is only possible when the two are different Symbol instances — i.e. the module was loaded twice and each instantiation called Symbol() anew.

Stack at failure:

at startCall      (.../agent-loop/lib/index.js:588)
at fillPool       (.../agent-loop/lib/index.js:646)
at runGroup       (.../agent-loop/lib/index.js:655)
at executeToolCalls (.../agent-loop/lib/index.js:528)
at ReactLoopAgent.step (.../agent-loop/lib/index.js:1136)

Why web-only

The cli profile loads @deepseek-ai/dsh-tools once, so the symbol identity matches and prepare resolves. The web profile's loading path produces a second copy (exact second-load entry point worth investigating — likely the cordis loader resolution / plugin-packaging boundary — but the symptom is fully explained by the identity mismatch regardless of where the second copy enters).

Suggested fix

Use the global symbol registry so identity is stable across any number of loaded copies:

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

Symbol.for(key) returns the same symbol for a given key from the global registry, regardless of how many times the module is instantiated. This is the canonical fix for cross-module symbol-identity bugs. I applied this locally (src + compiled lib); the prepare error no longer fires and tool calls dispatch correctly.

Follow-up

The deeper cleanup is to dedupe the double-load of @deepseek-ai/dsh-tools in the web profile so there is a single source of truth for the module. But Symbol.for is a safe, minimal, and correct fix that unblocks all web-profile tool calls today; the dedupe can follow.

[john-livingston]

Confirmed on macOS too, not Windows-specific. This is the "exact second-load entry point" you flagged as worth investigating: found it, with a direct reproduction.

Root cause

resolveModuleFallbackEntries's dependency traversal discovers every fallback package's declarer by walking some other package's own private pnpm node_modules (unavoidable given pnpm's isolated layout). For example, @deepseek-ai/dsh-agent-loop's declarer here is apps/cli/node_modules/@deepseek-ai/dsh-base/package.json, a real, valid path that reaches the actual package through a node_modules symlink hop.

resolver.ts's ESM adapter (adaptEsm) builds routedParent = pathToFileURL(route.entry.declarer).href for a fallback route and resolves the request from that parent. tsx's tsconfig-paths hook (the mechanism pnpm dsh's source launch depends on to map @deepseek-ai/dsh-agent-loop to packages/core/agent-loop/src) skips its rewrite whenever the literal parent path contains a node_modules segment, an ordinary safeguard against rewriting a genuinely external dependency's own requires. Since routedParent is built from the raw declarer path, it always contains node_modules, so the rewrite is always skipped for anything resolved this way, even though the real (symlink-resolved) location is squarely inside the repo and covered by tsconfig.base.json.

Verified directly by calling the same internal resolve hook installProfileResolution patches, under node --import tsx/esm, with both parent shapes (same real target directory, only the literal string differs):

resolveSync(parent = realpath of the declarer,      '@deepseek-ai/dsh-agent-loop') -> .../agent-loop/src/index.ts
resolveSync(parent = the raw symlinked declarer,     '@deepseek-ai/dsh-agent-loop') -> .../agent-loop/lib/index.js

Packages reached through the adapter's other branch (route.kind === 'native', a local candidate found by ordinary search) keep the caller's own unmodified parent, so they're unaffected; only some packages split, not all.

Fix

One line in packages/boot/app-boot/src/profile-resolution/resolver.ts, inside adaptEsm, using the file's own existing canonicalPath() (realpath) helper:

- const routedParent = pathToFileURL(route.kind === 'fallback' ? route.entry.declarer : route.parent).href
+ const routedParent = pathToFileURL(canonicalPath(route.kind === 'fallback' ? route.entry.declarer : route.parent)).href

This fixes module identity at the source rather than at one symbol: Symbol.for would paper over TOOL_RUNTIME_SCHEDULER specifically, but agent-loop is loading the wrong file entirely (its own lib/ instead of src/), which affects anything else relying on module-scoped state or identity across that boundary, not just this one symbol.

[Mywifi]

same on my win

[MoonShadow1976]

提交 commit ddefc45 版本稳定复现

回退到 commit c291e79 可正常使用

[ChenwxJay]

这个是官方代码改出问题了吗 2333

[MoonShadow1976]

新commit 46a7f68 正常了，但是之前出错的的对话历史记录加载不出来

历史加载失败：failed to observe session "session-a0b0b140-7ab4-494e-875d-4499a17281a9": Session migration from v3 to v4 refuses the transformed artifact: step/end leaves unresolved tool call call_00_ET_b3eCjln8id5BZRjXG7on0095; source v3 artifact remains unchanged (raw log: C:\Users\Administrator\.dsh\sessions\--C-Users-Administrator-Desktop-~5B89-~9053~8DEF~547D~540D~6574~5408--\session-a0b0b140-7ab4-494e-875d-4499a17281a9\session.v3.jsonl.zstd)（gateway/internal）

[dsh-community-assistant[bot]]

Thanks for the detailed reports. We've linked the source-launch prepare failure and the affected-session recovery reports to the existing investigation.

@MoonShadow1976 Your latest result distinguishes two things: tool calls work again on the newer commit, but the earlier session still cannot load because V3-to-V4 migration rejects an unresolved tool call. That means we cannot treat the affected history as recovered. We've recorded this remaining case separately within the investigation; please keep the original session log intact rather than deleting or editing its records.