[Bug] 0.2.1-rc.2: experimental Inspector terminates the Host at a ~69-byte retained-state budget gap (field crash, quantified)

[HaoyanZhang123]

Summary

The experimental Inspector plugin can terminate the Desktop Host with an uncaught exception when the live Cordis tree grows past a byte threshold. The defect is a byte-accounting gap of ~69 bytes between the component that prunes the tree snapshot and the component that validates it.

This is a field report from the shipped 0.2.1-rc.2 release build with a real, non-synthetic trigger. It adds quantitative evidence to discussion #9271, which described the same mismatch. As of 0.2.1-rc.2 the defect is still present — the fix from that thread is not in any published build I could verify.

Environment

Item	Value
App	@deepseek-ai/dsh-desktop 0.2.1-rc.2
Platform	Windows 11 x64
Electron	44.7.0
Node	24.21.0
Locale	zh-CN
Inspector	enabled by default via the @deepseek-ai/dsh-experimental-inspector-profile bundle

Crash report: %APPDATA%\@deepseek-ai\dsh-desktop\logs\crash-2026-10-19T05-44-49-773Z-host.log

Observed crash

phase: running
dsh: fatal uncaught exception: Error: inspector: source state exceeds the source-frame byte limit
    at InspectorSourceBuffer.setState (…/@deepseek-ai/dsh-experimental-inspector/lib/index.js:996:10)
    at HostBridgePublisher.setState  (…/lib/index.js:1109:16)
    at HostInspectorSource.setState  (…/lib/index.js:836:18)
    at …/lib/index.js:2322:13
    at publish (…/lib/index.js:2294:3)
    at node:internal/process/task_queues:151:7
    at AsyncResource.runInAsyncScope (node:async_hooks:227:14)
    at AsyncResource.runMicrotask (node:internal/process/task_queues:148:8)

Note on the stack: the frames below publish are the Host's own queueMicrotask path. The trailing main.js:3844 frame that also appears in this log file belongs to the Electron main process recording the host's exit, not to the Host's call chain.

Production trigger

A single run_code tool call contained a sequential for…of loop over 6 members, calling the subagent tool once per iteration. The spawns occurred 13:44:48.197 → 13:44:48.817. The host died at 13:44:49.773, i.e. ~1 s after the batch began.

• 5 child sessions were durably created before the crash.
• The 6th dispatch was recorded but never produced a result.
• The parent turn was closed by crash recovery as turn/end reason=interrupted at 13:44:48.817.

Caveat: the crash log contains no tree size or node count, so the causal link is temporal correlation plus a consistent mechanism — the Inspector publishes the whole Cordis tree on every internal/plugin / internal/status event, and each in-process subagent constructs fiber/plugin contexts. I am not claiming that 6 subagents is a hard threshold; the relevant condition is mutation while the retained snapshot is near its budget.

Why it happens

The retained-state path has two different byte budgets, and they measure different objects.

CordisTreeCollector.snapshot() prunes the bare payload:

// index.js:2191
while (jsonByteLength(snapshot) > this.limits.maxBytes) {

with the limit supplied by the publish site as payload-only:

// index.js:2404  (publishCordisTree call site)
maxBytes: spec.maxSourceFrameBytes - 4096

InspectorSourceBuffer.stateFits() instead measures the retained record wrappers:

// index.js:1082
stateFits() {
  return jsonByteLength([...this.state.values()]) + SOURCE_FRAME_OVERHEAD_BYTES
         <= this.options.maxFrameBytes;
}

where each retained value is { monotonicMs, topic, payload } (record(), ~1061). The envelope

{"monotonicMs":<epoch-ms>,"topic":"cordis/tree","payload":…}

costs 52–69 bytes depending on the magnitude of performance.now() (69 at realistic epoch-ms values), and the collector never accounts for it. Then setState() throws:

// index.js:993-996
if (!this.stateFits()) {
  …rollback…
  throw new Error("inspector: source state exceeds the source-frame byte limit");
}

So the collector prunes to 128*1024 - 4096 = 126976 bytes (DEFAULT_MAX_SOURCE_FRAME_BYTES, index.js:1752) while setState actually needs ≤ 126907 — a 69-byte danger band.

cordis/tree is the only retained state topic: createInspectorService() exposes publish but not setState, and line 2322 is the sole setState caller. So this is a pure accounting mismatch, not a multi-topic or concurrent-write race.

Quantitative model

Replaying the shipped pruneLast() loop against realistically shaped trees:

• Cost: ~127 bytes per fiber/node entry.
• The byte ceiling binds at ~978 nodes — well under the maxCordisNodes = 2048 cap, so byte pruning always fires before node truncation.
• Snapshots that needed pruning exited at 126950–126971 bytes.
• 123/123 and, in an independent rerun, 423/423 of prune-triggering snapshots landed in the danger band and would throw.

The band is 69 bytes and the prune step is ~128 bytes, so once pruning is required the loop is very likely to land inside the band. Model-based result, not a runtime measurement of the failing snapshot.

Why it is fatal rather than degraded

publish() / schedule() have no try/catch:

// index.js:2296-2300
const schedule = () => {
  if (scheduled || closed) return;
  scheduled = true;
  queueMicrotask(publish);
};

The throw happens inside the microtask, after the Cordis emitter that scheduled it has already unwound, so no caller can catch it. It surfaces as an uncaughtException, which installFailLoud (in dsh-app-boot) turns into proc.exit(1) after writing the dsh: fatal uncaught exception: line.

Note the asymmetry that makes this look like an oversight rather than a policy: non-retained publish() silently drops records that exceed the frame limit (enqueue(), ~line 1070), while retained setState() throws. A retained debugging topic should not be able to kill the Host.

Raising maxSourceFrameBytes does not help

This is the most tempting but wrong remedy: both ceilings (maxSourceFrameBytes - 4096 and maxSourceFrameBytes - 4096 - envelope) move together, so the gap is invariant at 128 KiB, 256 KiB and 1 MiB. Raising the limit only moves the cliff to a larger tree and makes the failure harder to attribute.

Suggested fix

Two layers, ideally both:

1. Root cause — make the budgets measure the same thing. Reserve the record envelope in the collector budget at the publish site (index.js:2404), e.g. maxBytes: spec.maxSourceFrameBytes - 4096 - 68, mirrored on the Client face (client.js:3534). Any change must be applied symmetrically to both the collector and stateFits(); adjusting only one reintroduces a gap.
2. Containment — never throw on a fire-and-forget publish path. setState should roll back (it already does), warn, and drop/replace with a truncated snapshot instead of throwing; and the queueMicrotask(publish) call should be guarded with try/catch. This removes the crash class regardless of future budget arithmetic.

Workaround

Disable the Inspector entry. In the composed profile (%USERPROFILE%\.dsh\profiles\desktop\cordis.yml) it appears as:

- id: experimental-inspector
  name: '@deepseek-ai/dsh-experimental-inspector'
  disabled: false        # set to true
  config:
    captureFetch: true

Because the composed profile is regenerated from bundles, the durable place for the override is the profile's cordis.patch.yml overlay — though I have not verified compose precedence in this build. Until fixed, keeping concurrent in-process subagents low also reduces exposure, since the Host dies as soon as byte pruning is required.

Related

• [Bug] Inspector Cordis-tree growth crashes Desktop Host: source state exceeds source-frame byte limit #9271 — same mismatch, with a proposed fix branch (not shipped in 0.2.1-rc.2 exactly as described here)
• [Bug] Desktop 0.2.1-rc.2: enabling the experimental "Developer tools" can crash the host after its inspector source closes — "inspector: Host source is closed" #10069 — inspector: Host source is closed, a different setState throw on the same publish path

No private conversation data, credentials, or unrelated filesystem paths are included in this report.