DSH plugin stuck on "Loading history": four root causes

When DSH hangs forever on "Loading history…" opening a particular session, re-clicking the same session does not retry, and only refreshing the page recovers it — at least four distinct root causes stack under this one screen symptom: waitForSocket() has no timeout fallback, the openState state machine has three holes, the Function.prototype.toString check is always false on Gecko/WebKit, and a single turn: null step block sits in the session log. All four look identical, so you cannot tell them apart from the screen alone; you must triage with three tests: "did the first frame arrive", "which browser engine is it", and "is there a turn: null in the log". This article splits into "the two client chains → the browser-compat chain → the data-shape chain", each with its test, paste-ready self-check commands, and a matching fix.

Two client defects: a socket waiter with no timeout + holes in the openState machine

These two are robustness gaps in the DSH client itself, independent of the browser engine, and reachable on any platform.

Symptoms: two scales, one presentation

The community report's scene was 0.1.7-rc.2, profile web, Windows 11, Node v24.20.0, with symptoms in two grades (#7802):

1. Hangs forever: the UI stays in the loading state, re-clicking the same session does not retry, and only a page refresh recovers it.
2. Seconds late: the same session sometimes merely appears a few seconds late, and a refresh also recovers it immediately.

The second grade is valuable: it shows this is not "the data is broken" but that the wait path itself is unreliable — a refresh rebuilds the whole connection, so the wait is bypassed.

Chain 1: waitForSocket() has no timeout, so a socket stuck in CONNECTING stays pending forever

The mechanism in three sentences: the waiter has no timeout, waking only happens on connection failure, and a socket stuck in CONNECTING is neither success nor failure. Specifically (#7802):

1. waitForSocket() has no timeout;
2. maintain() wakes the waiter only on connect failure;
3. keepAlive clears only after settlement.

⇒ When the socket is stuck in CONNECTING, the waiter stays pending forever and the UI stays in the loading state. The blast radius is all browsers (engine-independent); the offline reproduction of this chain in that thread is ✅, but direct evidence of socket.readyState at the moment of a real-machine hang is still missing (the author marks it unresolved; see the notes at the end).

Chain 2: three holes in doOpen / resync's state machine

The same UI symptom has a second, fully independent origin: the exception is thrown before the state is written. The three holes are (#7802, #6921):

1. The exception is thrown before writing openState ⇒ the state is never rewritten;
2. dispose() does not touch the state;
3. resync()'s dispose has no try/finally.

In @deepseek-ai/dsh-api-session-controller@0.1.5-rc.2 (lib/client.js:1979-2006) you can read this "no exit" shape:

:1994  await events.open({ maxMessages: 50 });
:1996  this.openState = "open";                    // exit 1: success
:1999  if (!isRemoteFailure(error)) throw error;   // non-remote error -> rethrow, state stays "loading"
:2001  this.openState = "error";                   // exit 2: remote failure only

Only two exits, and the second is reserved for remote failures. Any non-remote exception is rethrown and openState stays "loading" — the UI has no state to go to and can only show the loading text forever (community line-by-line review, #6921).

Numbered self-check: confirm whether it is 1/2, and whether you can self-rescue

1. Confirm "refresh recovers": go back to the session list, refresh the page, and click the same session again. Opens immediately ⇒ very likely in a client chain (1/2) or the compat chain 3.
2. Confirm "re-clicking does not retry": while stuck, click the same session row several times. If nothing changes, the waiter is not being rebuilt, matching chain 1's "waiter pending forever" (#7802).
3. See whether the remote session/follow first frame arrived: open the browser DevTools network panel and watch the remote session stream's first frame at the moment of the hang. Not arrived ⇒ likely chain 1/2; arrived but still loading ⇒ likely chain 3 (see the test table below).
4. Prefer a "switch browser" control: open the same session in Chrome/Edge. If it works immediately, chain 3 (compat) is pinned down; if it still hangs, go back to chain 1/2 (#7802).

Available fixes: a community patch set + a read-only probe

The community turned the three chains into installable artifacts (none official):

1. Patch set dsh-waitforsocket-timeout (MIT): covers 4 packages and three layers of problems; the script has idempotency, automatic backup, refuses on anchor mismatch (exit 2), and automatic rollback on syntax-check failure, and its anchors were byte-checked against official 0.1.7-rc.2 (#7802).
2. Read-only diagnostic probe dsh-open-watchdog (MIT, v0.3.0): fixes nothing, only records the timeline at the moment you "click a session row" as JSON (when the loading text appears/disappears, openState snapshots, network requests, browser-throttling evidence, whether open() finally resolved/rejected). The host-side route has four gates: loopback / Host / Origin / content-type (#7802).

One easy trap with the probe: when the browser is not on the host machine you must open the cross-machine switch, otherwise all four gates 403 and the browser side silently swallows it — appearing as "installed, route registered, but not a single record" (#7802):

# Option 1: explicitly allow origins (both default to empty => loopback only)
export DSH_OPEN_WATCHDOG_ALLOW_HOSTS="<the host your browser is on>"
export DSH_OPEN_WATCHDOG_ALLOW_PEERS="<allowed peers>"

# Option 2 (recommended, no gate widened at all): local port forwarding
ssh -N -L 3080:127.0.0.1:3080 <host machine>

The browser-compat chain: the toString check is always false on Gecko / WebKit

This one holds only on Firefox, Safari, and every browser on iOS/iPadOS; V8 engines like Chrome/Edge are fully immune — "switching browsers fixes it" is its fingerprint.

Mechanism: a hard-coded single-line comparison meets a multi-line return

The client uses hasIntrinsicConstructor to decide whether a value can be losslessly JSON-serialized, by comparing the result of Function.prototype.toString against a hard-coded single-line form. The problem:

1. Gecko / WebKit return a multi-line form for built-in functions;
2. So the comparison is always false;
3. ⇒ Every plain object is judged "not lossless JSON", and session loading cannot proceed (#7802).

The UI symptom is identical to chains 1/2 (both stuck on "Loading history…"), because the upstream doOpen rethrows first and writes the error state second, so even hitting the compat chain the UI only shows the loading text (#7802).

A one-line self-test: confirm whether your engine is affected

Run this line in the affected browser's console; if the result contains a newline, you are affected. The command-line equivalent:

node -e "console.log(/\\n/.test(Function.prototype.toString.call(Object)))"

In a browser console that is:

Function.prototype.toString.call(Object)
// if the result contains a newline => your engine hits this check (Gecko / WebKit)

Test table: how to tell the three chains apart

(The test table is from the community summary.)

Note chain 3's scope: on 0.1.7-rc.2 the community clarifies that only a response currently being generated fails (the client only validates the current attempt's raw chunk, api/session-controller/src/client/sessions/assistant-stream.ts:79-82); completed conversations load fine (#7802).

An upstream-direction community fix already has tests

A contributor submitted the branch fix/values-native-source-whitespace: a regression test (fails before the fix / passes after) + all 5,827 tests across 238 files in 17 packages pass + clean typecheck + a 45-case V8 / JavaScriptCore comparison; the fix follows the same path as the community patch — normalize whitespace before comparing, keep the toString check. The community author states clearly: if upstream adopts it, their patch should retire (#7802).

Handle chain 3 with steps 1/2/3:

1. Work around first: open the session in a V8-based browser (Chrome / Edge) and confirm it loads.
2. Confirm the scope: only a response currently being generated fails while completed conversations open ⇒ this is chain 3's rc.2 behavior.
3. Wait or patch: wait for upstream to merge the fix with regression tests; if you must self-rescue, the community patch set works, but note it anchors to official versions and must be re-checked before upgrading.

The data-shape chain: one turn: null step block in the log

The essential difference from the previous three is that this one is "data-shape-driven" — no matter how big the session, a single unattributable step block makes the client render state machine spin. It comes from another production measurement (#6921).

Key premise: the data layer is healthy

The affected session had about 330,000 events, 724 messages, 2 frames (macOS 26.3 arm64, DSH 0.1.1-rc.2 line). Before touching anything, the author checked the whole log with read-only tools (#6921):

More important is the size comparison: in the same environment sessions with about 690,000 and about 360,000 events open fine, while the problematic one with about 330,000 does not ⇒ size alone does not decide it (#6921).

The only anomaly: three consecutive turn: null

The full scan found exactly one structural anomaly — three consecutive events carrying turn: null:

seq 580037  step/start        turn: null
seq 580038  assistant/message turn: null   <- replace marker
seq 580039  step/end          turn: null

These three are the surface-replace marker written when a message was edited: the marker recorded the edited node but did not fill in turn (#6921).

Numbered steps: locate and fix this block

1. Back up first: copy the session's log file elsewhere (you must leave a way back before rewriting).
2. Scan for turn: null: run a structural scan over the log for consecutive blocks of step/start → assistant/message → step/end with data.turn unset. Sketch (read-only, no write-back):

# Read-only scan: list all events whose data.turn is null (adjust the field path to your log format)
jq -c 'select(.data.turn == null) | {seq: .seq, type: .type, turn: .data.turn}' session.jsonl

3. Confirm "which turn was open at the time": look around the block for the nearest preceding turn/start (in this case turn 95) — that is the turn it should belong to.
4. Change these three events' turn from null to that turn, leaving every other field untouched.
5. Verify: rerun the contract checker (expect 0 violations), the official load still gives 724 messages, the turn: null count is zero; then open the session, which should render normally.

The author's own words: "Changed these 3 events from turn: null to the turn actually open at the time (turn 95) — changed nothing else", and the client then opened normally (#6921).

Three fix directions and their costs (community advice to maintainers)

The community does not claim this is an official patch but offers three directions (#6921):

1. Give the open state machine an exit for every failure, not just remote ones: set "error" for every failure (keeping a typed payload for remote errors), or add a third terminal state meaning "opened but cannot render". The cost is that some callers currently rely on non-remote errors propagating outward; a separate terminal state avoids the conflict. The author considers this the first of the three to do — it decides between "one failure" and "one hang".
2. Make unattributable steps non-fatal at the render layer: treat a step/marker with no turn as unrenderable, skip it, and keep rendering the rest. State the cost clearly: skipping hides content, and readers cannot tell "nothing happened" from "something was skipped"; so the community argues for a visible notice (e.g. a line in the conversation: "1 event could not be attributed and was skipped") rather than a silent skip.
3. Offline detection (detect only, do not fix): run a structural scan before opening a session, turning "the app cannot open my session" into "this session has one malformed block" ahead of time.

An important cross-reference: the same batch of reports includes #6942 / #6949 / #6952 / #6953 / #6954, whose common shape is "zero tolerance for unexpected input + an error boundary swallowing the exception ⇒ the user sees silence" (blank screen, no notice). When troubleshooting, if "the data is healthy but the UI is blank", lean toward this pattern (#6921).

Troubleshooting notes

One "Loading history…" has at least four root causes; triage with the tests before acting, and above all do not start by editing session data. Nine points:

1. Whether a refresh recovers is the cheapest first cut: it recovers ⇒ client chain; it does not ⇒ look at first-frame size or data shape (#7802).
2. Use a browser switch as a control: a V8-engine switch fixes it ⇒ the chain-3 compat problem; all hang the same ⇒ chain 1/2 (#7802).
3. A one-line engine check: Function.prototype.toString.call(Object) containing a newline means the compat check holds (#7802).
4. Chain 1's CONNECTING is still inferred: the community itself admits direct evidence of socket.readyState at the hang is missing; do not treat it as settled (#7802).
5. Chain 2's "trigger" is undetermined: one place attributes it to dispose(), another to connection generation; neither reproduces a generation change on connection/reset, and direct logs are missing (#7802).
6. Do not treat size as the only test: sessions with about 690k and 360k events open fine, while one with about 330k does not (#6921).
7. Same symptom, not same cause: #4513 / #4416 are scale/performance-type (host event loop and browser main thread double-blocking, measured 535,316 events), unlike this article's data-shape type; #7754, #6966 (first frame of 4–9 MB fully pushed), and #6978 (parse cost) are yet other chains (#7802, #6921).
8. Credit prior art honestly: chain 2 was first reported in #7527 (2026-09-22), chain 3 first localized in #5919 (2026-09-08) and #5677 (2026-09-04), and a near-report of chain 1 is #5056 (2026-08-29) — the community itself stresses "not one of the three chains is ours to have found first" (#7802).
9. Always back up before changing a session log: the turn: null fix rewrites events directly, and a mistake creates new malformed data; back up, scan, rewrite, then verify with the contract checker.

When troubleshooting UI-hang problems like these, if you manage plugin installs, update confirmations, system logs, and diagnostics together in DSH Plugin Hub, you can at least first confirm on the installed list whether a particular plugin version caused the load failure before touching session data.

Source: Discussion #7802, Discussion #6921.