[Bug] messages protocol: prepare undefined crash on tool_use, then INVALID_REQUEST on retry

[xiongmao221108]

Environment

• DSH version: 0.1.6-alpha.2 (source deploy)
• OS: Windows 11
• Provider: deepseek-official (default deepseek-flash)
• Protocol: messages (default)

Steps to Reproduce

1. Start pnpm dsh web, open Web UI
2. Send a message that triggers tool calling (e.g. ask the model to search, read files, or use any MCP tool)
3. Model returns tool_use blocks
4. DSH client crashes with: Cannot read properties of undefined (reading 'prepare')
5. On the next turn (or retry), DeepSeek API rejects with: INVALID_REQUEST: DeepSeek Messages tool calls need immediate results

Expected Behavior

Tool result should be prepared and sent back to the API as tool_result blocks following the tool_use assistant message.

Actual Behavior

1. Client-side JS error: Cannot read properties of undefined (reading 'prepare') — the tool result preparation step crashes
2. Because tool results are missing from the conversation, the next API call fails with INVALID_REQUEST: tool calls need immediate results (the messages protocol requires tool_result blocks immediately after tool_use)

Root Cause Hypothesis

In messages (Anthropic) protocol mode, the tool result serialization path references a prepare method on an object that is undefined. This may be a missing null-check or a race condition where the tool handler isn't fully initialized before results are expected.

Workaround

Switch to chat-completions protocol (works fine):

llm-deepseek:
  protocol: chat-completions
  baseURL: https://api.deepseek.com/v1
  apiKeyEnv: DEEPSEEK_API_KEY

Logs

Cannot read properties of undefined (reading 'prepare')
UNKNOWN

DeepSeek Messages tool calls need immediate results
INVALID_REQUEST

[PerryLink]

Your hypothesis is testable against the source, and it does not hold: this is neither protocol-specific nor a race. The messages protocol is not involved at the crash site at all.

The crash happens before any serialization

The throw site is packages/core/agent-loop/src/tool-calls.ts:170:

const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)

That file imports nothing protocol-related. Its complete value-import list is packages/core/agent-loop/src/tool-calls.ts:14-18: @deepseek-ai/cordis, @deepseek-ai/dsh-llm (types plus createToolResultMessage), @deepseek-ai/dsh-session, @deepseek-ai/dsh-tools, @deepseek-ai/dsh-util-values. Protocol selection lives in the provider adapter — packages/llm/llm-deepseek/src/adapter.ts:22 and :36 — which chooses between protocols/messages/ and protocols/chat-completions/. The tool scheduler runs in the agent loop, upstream of both. ctx.tools is the ToolRuntime service (packages/core/tools/src/index.ts:829, super(ctx, 'tools')), and it never imports a protocol module either.

Nothing here is a race, and nothing is partially initialized: the scheduler is a plain computed class field assigned at construction, packages/core/tools/src/index.ts:797-803, and it is read long after the plugins are up. What you are indexing into is simply not the object you think it is — see below.

Why chat-completions looks like it helps

Because the harness enforces the tool-call/tool-result pairing locally only on the messages path. packages/llm/llm-deepseek/src/protocols/messages/serialize.ts:106-121 walks the history with a pending set and throws DeepSeek Messages tool calls need immediate results (:117) when an assistant tool call has no matching result. The chat-completions serializer has no equivalent walk — every check of that kind in it is about images (packages/llm/llm-deepseek/src/protocols/chat-completions/serialize.ts:103-118, :143-147), nothing about dangling tool calls. So the orphan is not caught at request-build time — I have not re-run your scenario to see which of the two the server does with it (reject with a generic 400, or accept and let the model continue without that result), but either way it is not a repair.

The crash is unchanged: the next tool call you trigger hits tool-calls.ts:170 again and dies the same way, so what changed is the error text, not the behavior. The transcript is still left with an unresolved tool call, because the throw happens after appendToolCall at :168 and results are only produced through commitReady → appendToolResult at :156. Reopening or retrying does not repair it: the turn closes with turn/end { kind: 'error' }, and interruptedTurnClosers bails out when no turn is open (packages/core/session/src/repair.ts:82), so no synthetic result is generated for the orphan.

The actual cause

Two module instances of @deepseek-ai/dsh-tools exist in the process, and the lookup key is module-local:

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

Symbol(...), not Symbol.for(...), so each instance creates its own key. ToolRuntime registers its scheduler under one instance's key (packages/core/tools/src/index.ts:798); tool-calls.ts reads under the other's (:170), gets undefined, and throws on .prepare.

The two planes, in a built source checkout:

• dsh runs node --import tsx/esm apps/cli/src/bin.ts (package.json:189), and tsconfig.base.json:484 maps "@deepseek-ai/dsh-tools" to packages/core/tools/src — the agent loop's import of the symbol (packages/core/agent-loop/src/tool-calls.ts:17) lands on src/index.ts.
• The plugins the profile mounts resolve through the fallback link $DSH_HOME/profiles/node_modules/@deepseek-ai/dsh-tools, which points at the package directory (packages/boot/app-boot/src/profile.ts:668), and Node then follows that package's exports field — "default": "./lib/index.js" (packages/core/tools/package.json:19).

Both files exist once you have built, and both call Symbol(...): packages/core/tools/src/index.ts:463 and the compiled packages/core/tools/lib/index.js:2526.

Why your setup started doing this: apps/cli/src/profile-boot.ts:263 now reads const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'runtime'. Commit 9ddef327a40dc8d128a1d8b912fc17677ddf0ed8 flipped that default from 'link' to 'runtime'; the last tag that still defaults to ?? 'link' is dsh-v0.1.6-alpha.1 (0a15e36e7f, apps/cli/src/profile-boot.ts:305); dsh-v0.1.5-rc.2 (fb2c4b9e69) does not reproduce it either, but only because it predates resolutionMode entirely. No CLI flag or env var overrides it — apps/cli/src/args.ts defines no resolution option and apps/cli/src/bin.ts:38 calls runProfile without one. It is not Windows-specific either; macOS reporters hit the same path.

Workarounds

1. Use the built entry: node apps/cli/lib/bin.js web (or node apps/cli/lib/bin.js --profile headless …). Every resolution then lands on lib/, one symbol is shared, and tool calls work. Requires a completed pnpm run build.
2. Revert the default at apps/cli/src/profile-boot.ts:263 to ?? 'link', which is what dsh-v0.1.6-alpha.1 shipped. No rebuild and no reinstall needed for pnpm dsh — but it fails the committed test at apps/cli/tests/resolved-profile-boot.spec.ts:94 and is overwritten on upgrade.
3. Roll back to dsh-v0.1.6-alpha.1 (0a15e36e7f) — same mechanism, still 'link' — or to dsh-v0.1.5-rc.2 (fb2c4b9e69), which predates the feature.

Your chat-completions config is not doing what you think, so I would not rely on it as a workaround — it moves the failure rather than removing it.