Bug: reopening an existing session shows a blank chat (Assistant stream raw chunk must be a lossless JSON object), and approval dialogs lose their command text

[pbh4]

I'm reporting a bug (I don't have issue permissions, so posting here — maintainers: happy to help move it to Issues / provide more logs).

Version: @deepseek-ai/dsh 0.1.3-alpha.1 (dev checkout, dsh web, web profile) · Node v24.19.0 · Linux

Symptom: after a dsh web restart, opening any session that predates the current process shows a permanently blank chat. The session list renders fine and brand-new sessions work, but existing conversations never display their history. While the chat is in that state, approval/consent dialogs also show an empty command area (only the reason text renders).

No data is lost — the on-disk session logs are intact, and the server-side read path returns the full history for every session.

Browser console shows, repeatedly:

Uncaught TypeError: Assistant stream raw chunk must be a lossless JSON object
Caused by: TypeError: Assistant stream chunk must be losslessly JSON-serializable
assistant-stream.ts:261:15
[session-controller] event feed subscriber failed: TypeError: Assistant stream raw chunk must be a lossless JSON object

Repro steps:

Start dsh web, have a normal conversation that includes tool calls / assistant streaming.
Restart dsh web.
Open that existing session → blank chat + the console error above.
While blank, trigger an escalation approval → the card shows the reason but no command text.

New sessions created after a restart display fine until they are reopened after a later restart.

Root-cause analysis (client-side): validation in the assistant-stream module (assistant-stream.ts, validateRecord/snapshotChunk) throws when a replayed stream chunk record's payload is not a losslessly JSON-serializable plain object. expandAssistantStream then aborts the whole replay → the conversation never assembles → blank chat and the [session-controller] event feed subscriber failed cascade. The approval panel is affected for the same reason: its command box is filled by ApprovalCommand (dsh-client-ui-chat), which looks up the matching tool-call node in the same (broken/empty) conversation snapshot — no node, no command text. I could not isolate which specific chunk payload trips the check; it appears during reconstruction on replay, not in the stored JSONL.

Workaround (local, not a fix): patched the embedded expandAssistantStream in the four installed client bundles (dsh-client-ui-chat, dsh-client-ui-trajectory, dsh-api-session-controller, dsh-client-connection → lib/client.js) to skip records that fail validation instead of throwing:
js

for (const candidate of stream) {
let record;
try {
record = validateRecord(candidate);
} catch {
continue;
}
...
}

After this, history renders again and approval dialogs show their command text. Session data was never modified.

Suggestions for maintainers: (1) root-cause the replayed chunk that fails lossless-JSON validation on resume; (2) make expandAssistantStream skip/log a single invalid record instead of killing the whole conversation; (3) consider rendering cold history independently of the live assistant-stream replay (the read path already supports this).

Happy to provide more details, logs, or test builds.

[Saidoua]

This is not a stored-chunk problem — the payload that "trips the check" is every plain object, and the trigger is the browser. Are you on Firefox or Zen? I believe this is the same root cause as #5677 / #5709, already fixed on master.

Why the replayed chunk looks corrupt. hasIntrinsicConstructor() in packages/util/values/src/index.ts decides whether a prototype is a realm-owned intrinsic by comparing the exact string form of its constructor:

Function.prototype.toString.call(constructor) === `function ${name}() { [native code] }`

ECMAScript leaves that rendering implementation-defined. V8 emits one line; SpiderMonkey emits three. On a Firefox-engine browser every plain object therefore fails isIntrinsicObjectPrototype(), snapshotJsonValue() returns undefined for ordinary JSON, and snapshotChunk throws — which is exactly the cause chain in your console.

Your "new sessions work, reopened ones don't" detail is the giveaway, and it is the part that made this look like a replay-only data problem. Live streaming renders from assistant/chunk events, which never reach expandAssistantStream. Reopening a session replays the completed stream embedded in assistant/message.data.stream, and that path validates every record. So one broken guard produces precisely your split: live fine, reopened blank. The approval-dialog symptom follows from the same cascade, as you diagnosed — ApprovalCommand reads the conversation snapshot that never assembled.

Reproduced. Stubbing only the native-function rendering to SpiderMonkey's form and expanding an ordinary stored stream:

TypeError: Assistant stream raw chunk must be a lossless JSON object
Caused by: TypeError: Assistant stream chunk must be losslessly JSON-serializable

Byte-identical to yours. Under V8 rendering the same stream expands cleanly, which is why Chromium users never see it.

The fix collapses whitespace before comparing, at the four mirrored sites (util/values, core/tools/json-schema.ts, cordis-host-runner/guard.ts, code-runtime-worker-thread/worker-json.ts). It cannot widen the check: function Object() { [native code] } is not parseable JavaScript, so no user-authored function can render to that text under any whitespace. The worker-thread copy needs a regex-free collapse — that file captures its intrinsics at load to resist prototype tampering, and String.prototype.replace would reopen it.

Reference patch: Saidoua@d68ea1a

On your local patch: once the guard is engine-tolerant you should not need it, and I would drop it rather than keep it — skipping records that fail validation would have hidden this bug instead of surfacing it, and on an affected browser it silently discards every chunk. Your suggestion (2) is a real design question independent of this bug — whether one invalid record should blank a conversation — but it is worth deciding on its merits rather than as a workaround for this.

If you are on Chromium and still hitting it, then it is a genuinely different defect and worth saying so, because the fix above will not help you.

[novalex]

+1, independently root-caused the same thing on 0.1.5-rc.2 (Firefox, macOS, server Node v22.22.1) — confirming SpiderMonkey's multi-line native Function.prototype.toString vs the exact-string fingerprint in hasIntrinsicConstructor.

Extra data points from a full trace (disk, wire, and browser all inspected live):

• Stored JSONL, the WS wire, and the parsed browser payloads are all valid — the failing object was an ordinary {type:"block-start", index:0, blockType:"reasoning"} that passes every descriptor-level check; only the validator's realm fingerprint is broken. So the "make expandAssistantStream skip invalid records" idea would silently drop every chunk on affected browsers — agreed with the reply that it should not be used as a workaround.
• On 0.1.5-rc.2 the visible trigger is opening a conversation while an attempt is live (client adopts the reconnect baseline in ClientAssistantStream.replace() → expandAssistantStream); settled replays no longer run the client-side validator, which is why "reopen after it finishes" works. The blank-chat-after-restart repro in this thread is the same guard on the replay path of older bundles.

Workaround in use: whitespace-normalize the comparison in the two browser-served copies (dsh-api-session-controller/lib/client.js, dsh-client-connection/lib/client.js); Node-side copies are format-compatible anyway.