Web chat pinned on "Loading history…" forever when a live assistant baseline fails validation

[kevinchiha]

Summary

session.follow includes the host's in-memory copy of an in-flight assistant
attempt in its opening snapshot. The host folds those frames as trusted and never
validates chunk shape. The browser validates them strictly during the first
window install. When a chunk fails, expandAssistantStream throws a plain
TypeError, and every handler on the open path recognises only RemoteError.
The TypeError is rethrown before openState is ever assigned, so the chat
stays on "Loading history…" with no error surface, no timeout and no retry.

Users see a chat that never loads. Reloading does not help, because the same
baseline is served again. It clears only when the host drops the attempt.

Present in 0.1.5-rc.1 and unchanged in 0.1.6-alpha.1.

Reproduction

Against a running dsh web, intercept the gateway socket and attach an
activeAttempt whose stream carries one non-object chunk to the opening
snapshot frame:

frame.value.assistantStream = {
  revision: 1,
  activeAttempt: {
    attemptId: 'repro', startedAfterSeq: lastSeq, turn: 1, step: 1, nextIndex: 1,
    stream: [{ type: 'chunk', time: Date.now(), chunk: 'not-an-object' }],
  },
};

Result: the chat column shows chat.loadingHistory indefinitely, zero rows, no
openError, and the console carries an unhandled
TypeError: Assistant stream raw chunk must be a lossless JSON object.
Observed for 30 s, and in the wild for minutes across repeated hard refreshes.

Chain

All paths in @deepseek-ai/dsh-api-session-controller.

1. lib/index.js — SessionAssistantStreamAccumulator retains live frames for
   reconnecting web followers, documented as folding "one trusted frame". No
   chunk validation.

2. lib/index.js — follow() emits
   assistantStream: this.assistantStreams.get(target)?.snapshot() ?? { revision: 0 }
   in the opening snapshot.

3. lib/client.js — ClientAssistantStream.replace() calls
   expandAssistantStream(opening.stream), which runs validateRecord and
   throws TypeError for a chunk that is not a lossless plain JSON object.

4. That call sits under installWindow → acceptEventChange('replace') →
   RemoteJournalStream.replaceFromOpening → publish, inside open()'s try
   block, so it rejects events.open().

5. lib/client.js — doOpen:

   } catch (error) {
     if (generation !== this.openGeneration || this.events !== events) return;
     if (!isRemoteFailure(error)) throw error;   // openState still "loading"
     this.events = void 0;
     this.openState = "error";
     this.openError = error;
   }

   isRemoteFailure requires isDSHRemoteError === true, so a TypeError
   escapes. openState is never moved off "loading".

6. followCurrent() calls record.session.open() with no .catch(), so the
   rejection is unhandled and nothing re-opens: followCurrent returns early
   while current === this.watched.

failEventStream has the same shape, so a non-RemoteError raised by the
background consumer also throws out of a callback rather than settling state.

Why storage looks clean

Only the live copy is affected. Validating every stored assistant stream with
the shipped browser validator gave zero rejections over 13,502 streams in 567
sessions. A malformed durable event behaves correctly and renders
chat.loadError. The asymmetry is that durable events cross a validating
boundary and the live baseline does not.

Suggested fixes

1. Validate the accumulator's frames on the host, at the point they are folded,
   so a bad chunk cannot reach the wire and fails where it can be attributed.
2. Make the browser's open path total. doOpen and failEventStream should
   settle openState for every error class, not only RemoteError; rethrowing
   inside a callback leaves the UI with no way back.
3. Treat an unreadable live baseline as recoverable in
   ClientAssistantStream.replace(): drop the transient tail, keep the durable
   window, let live frames resync. The in-flight text arrives again anyway.

Fix 2 alone converts a dead screen into a visible error. Fix 3 keeps the session
usable. We are running 3 locally as a patch.

Environment

• @deepseek-ai/dsh 0.1.5-rc.1, @deepseek-ai/dsh-api-session-controller 0.1.5-rc.2
• Node 24.21.0, Linux, Chromium
• Also checked @deepseek-ai/dsh-api-session-controller@0.1.6-alpha.1: the
  doOpen and failEventStream handling is byte-identical.

[PerryLink]

Your chain is confirmed against HEAD (ddefc45fbc, v0.1.6-alpha.2) — the code is unchanged from what you describe, and your fixes map cleanly onto it.

The escape path is exactly packages/api/session-controller/src/client/sessions/session.ts:605-613:

} catch (error) {
  if (generation !== this.openGeneration || this.events !== events) return
  if (!isRemoteFailure(error)) throw error
  this.events = undefined
  this.openState = 'error'

with this.openState = 'loading' set at :588. The TypeError originates where you say: expandAssistantStream in packages/llm/llm/src/assistant-stream.ts throws TypeError('Assistant stream raw chunk must be a lossless JSON object') (:492, :498), it's invoked by ClientAssistantStream.replace (packages/api/session-controller/src/client/sessions/assistant-stream.ts:73-75) ← installWindow (session.ts:648) ← events.open() inside doOpen's try (:601-602). failEventStream (:774-784) has the same if (!isRemoteFailure(error)) throw error at :776, as you noted.

One naming drift: HEAD has no followCurrent; the equivalent flow is retain() → attachOpening(this.manager.get(id).open(), signal) (service.ts:294), and ClientSessionReference.attachOpening (service.ts:203-218) rejects ready with the same error while void this.ready.catch(() => {}) (service.ts:195) swallows it — nothing ever settles openState. The substance of your point 6 holds.

Your "storage looks clean" asymmetry is also source-supported: durable entries are wire-validated (assertSessionWireEvent in transport.ts:217 and :233), while the live assistant baseline is folded without validation — exactly the boundary you drew.

On the fixes: fix 2 (settle openState/openError for every error class in doOpen and failEventStream) is the minimal correct change at session.ts:607 and :776, and alone turns the dead screen into a visible error. Fix 3 (treat the baseline as recoverable inside ClientAssistantStream.replace) keeps the session usable since live frames resync anyway — your local patch of it I can't verify, but the code path supports the idea.

Not verified: your 13,502-stream validation sweep and the 30s/wild observations are your measurements.

If you capture the exact frame shape that triggered it in the wild, it'd be useful for anyone proposing a fix.