[Bug][Desktop 0.2.1-rc.3] Opening a single-turn session wedges the chat view on "Loading history…" forever, with no error shown

[Katharsis-I]

[Bug][Desktop 0.2.1-rc.3] Opening a single-turn session wedges the chat view on "Loading history…" forever, with no error shown

Summary

On the desktop client, opening one particular session leaves the conversation pane stuck on
Loading history… (chat.loadingHistory) indefinitely. It never resolves and never shows an
error, so there is no way for the user to tell what went wrong or to recover — the only escape is
to switch to a different session.

The session in question has exactly one turn/start event and more than maxMessages worth of
history. Because paginate() cannot satisfy both of its stop conditions, it returns the entire
log (cut = 0, hasMore = false) as the opening snapshot. On the client side, Session.doOpen()
only surfaces remote failures; any other error thrown while receiving that oversized opening
snapshot is rethrown and swallowed, leaving openState pinned at "loading" and openError at
null.

Environment

• DeepSeek Harness Desktop 0.2.1-rc.3 (Electron 44.7.0, Node 24.21.0)
• Windows 11 (win32 x64), locale en
• Profile: local desktop profile, third-party plugins loaded
• Affected session: session-6fc6e014-cfcd-401a-af89-34b900b32841
  • session.v4.jsonl.zstd, 1,233,828 bytes on disk
  • 1,017 wire events, 3.93 MB after wire serialization
  • turn/start = 1, turn/end = 1 (reason interrupted)
  • assistant/message = 147, user/message = 9 (of which 1 is human-authored, 8 are injected
    runtime/system/time context), tool/call = 172, tool/result = 172

Steps to Reproduce

1. Have a session whose log contains only a single turn/start and more history than one page.
   The simplest way to end up here is a long single-turn session that is later interrupted:
   the turn is started once, the user never sends a second message, and the run is cancelled —
   so no second turn/start is ever written.
2. Open that session in the desktop client (click it in the session list, or restore it as the
   last-opened session so it opens on startup).
3. Observe the conversation pane.

Reproduction is deterministic for the affected session and does not depend on machine load; other
sessions in the same profile open normally.

Current behavior

• The conversation pane shows Loading history… forever.
• No error message, no timeout, no retry affordance. chat.loadError ("Failed to load history:
  {message} ({code})") is never rendered because openError is never set.
• The rest of the UI stays usable — this is not a process crash, and no crash-*-host.log is
  produced for it. The main window can still switch to other sessions and those load fine.
• If this session is the dsh.sessions.current entry, startup appears to hang on it.

Expected behavior

Either of these would be acceptable:

• The history loads (paging the log), or
• The pane shows the existing failure surface — Failed to load history: … (…) — instead of staying
  on the loading hint forever.

A permanent, silent loading state is the core defect: an unrecoverable condition is presented as a
normal in-progress state.

Root cause analysis

1. paginate() cannot terminate for a single-turn session

paginate(events, beforeSeq, maxMessages, throughSeq, turnWindow) walks the log backwards and only
sets cut at one of two breaks:

function paginate(events, beforeSeq, maxMessages, throughSeq, turnWindow) {
	const end = SessionLogOffset(Math.min(throughSeq + 1, beforeSeq ?? throughSeq + 1));
	let count = 0;
	let turns = 0;
	let cut = SessionLogOffset(0);
	for (let index = end - 1; index >= 0; index--) {
		const event = events[index];
		if (turnWindow !== void 0 && event.type === "turn/start") {
			turns++;
			if (count >= turnWindow.minMessages && turns >= turnWindow.minTurns) {
				cut = SessionLogOffset(index);
				break;
			}
		}
		if (!MESSAGE_TYPES$1.has(event.type) || !isAppendSurfaceEvent(event)) continue;
		count++;
		// ...
		if (count >= maxMessages) {
			cut = SessionLogOffset(groupStart);
			break;
		}
	}
	return { events: events.slice(cut, end), hasMore: cut > 0 };
}

with

const DEFAULT_MAX_MESSAGES = 50;
const MESSAGE_TYPES$1 = new Set(["user/message", "assistant/message"]);

and the client passing, for the opening page:

const HISTORY_PAGE_OPTIONS = { maxMessages: 500, turnWindow: { minMessages: 50, minTurns: 2 } };

For the affected session:

• The turn/start break requires turns >= 2, but there is exactly one turn/start in the
  whole log, so turns never reaches minTurns and that branch never fires.
• The maxMessages break requires count >= 500, but count only increments for
  user/message / assistant/message events: 147 + 9 = 156, so it never reaches 500 either.
  (Worth noting explicitly: this means a single-turn session can return vastly more than
  maxMessages events — 1,017 here — while never tripping the message cap. The cap constrains
  messages, not snapshot size.)

The loop therefore runs to index < 0 without breaking, cut stays 0, and the function returns
the entire log with hasMore: false. That value is used verbatim to build the opening snapshot:

const page = paginate(events, void 0, request.maxMessages ?? DEFAULT_MAX_MESSAGES, cursor, request.turnWindow);
yield { type: "snapshot", header: wireHeader(source.header), cursor, records: pageRecords(page.events), hasMore: page.hasMore, projections: ... };

The documented intent of this option is "Stop at a Turn start after both minima, unless
maxMessages or history exhaustion wins" — history exhaustion is winning here, and that is by
design. The problem is that the resulting snapshot is effectively unbounded for one-turn sessions,
and nothing downstream handles that well.

2. Session.doOpen() swallows non-remote errors, pinning the UI on loading

async doOpen(generation) {
  this.openState = "loading";
  this.openError = null;
  this.notifier.markDirty();
  const events = new SessionEventStream(this.remote, this.sessionAddress(), { ... });
  this.events = events;
  try {
    await events.open(HISTORY_PAGE_OPTIONS);
    if (generation !== this.openGeneration || this.events !== events) return;
    this.openState = "open";
  } catch (error) {
    if (generation !== this.openGeneration || this.events !== events) return;
    if (!(0, _deepseek_ai_dsh_api_gateway_client.isRemoteFailure)(error)) throw error;
    this.events = void 0;
    this.openState = "error";
    this.openError = error;
  } finally {
    if (generation === this.openGeneration) this.notifier.markDirty();
  }
}

isRemoteFailure is remoteErrorOf(error) !== undefined, and remoteErrorOf accepts only objects
carrying isDSHRemoteError === true and a string code:

function remoteErrorOf(v) {
  return typeof v === "object" && v !== null && v.isDSHRemoteError === true && typeof v.code === "string" ? v : undefined;
}

So a plain Error / TypeError thrown anywhere inside events.open(...) — including from
assertSessionWireEvent, from the carrier (RemoteStreamCarrierError), or from the transport —
is rethrown, and neither openState nor openError is updated. The finally block then calls
markDirty(), so the UI re-renders and commits to the loading state permanently:

openState === "loading" && jsx("div", { className: ..., children: t("chat.loadingHistory") }),
openState === "error" && openError !== null && jsx("div", { className: ..., children: t("chat.loadError", { message: openError.message, code: openError.code }) }),

Two independent things go wrong: the error is not classified as a displayable failure, and the state
machine has no transition out of loading other than success or a remote failure. There is no
timeout and no fallback.

Direct verification

• All 89 session files in this profile were decompressed frame-by-frame (session.v4.jsonl.zstd is
  a concatenation of independent zstd frames, one per record): 0 decompression failures, 0 JSON
  parse failures.
• All 89 sessions were validated against the full assertSessionWireEvent contract (the 7-key
  envelope whitelist, the 61 known event types, surfaceOp rules, sourceEventSeqs rules, and the
  per-type data validators): 89/89 pass, zero violations. So the on-disk log is not malformed —
  this is not corrupted data, it is a valid log that the paging/snapshot path cannot handle.
• Replaying paginate's exact loop over all 34 sessions in this workspace shows the affected session
  is the only one that returns hasMore = false with a page larger than maxMessages:
  6fc6e014 evs=1017 cut=0 pageLen=1017 hasMore=false. Every other session has cut > 0,
  pageLen between 190 and 1666, and hasMore = true.
• Measured opening cost per session (decompress + wire serialize, from the tail): 0.9 ms – 486.7 ms.
  The affected session's 1,017 events serialize to 4,122,140 bytes; the largest single event is
  102,713 bytes (assistant/message at seq 879), and the single request/header is 88,981 bytes
  (97 tool schemas).
• Archived copy of the affected session was exported and read back to confirm nothing was lost.

Suggested fixes

Immediate mitigation (user-side, no code change needed): rename the session file out of the
way so the session no longer resolves (rejectNotFound → a proper remote error → the pane shows
Failed to load history instead of hanging).

Client-side (the important one): make doOpen fail closed instead of open.

} catch (error) {
  if (generation !== this.openGeneration || this.events !== events) return;
  this.events = void 0;
  this.openState = "error";
  this.openError = error;   // wrap non-remote errors, or at least do not rethrow
}

If rethrowing is intentional (so the caller can handle it), then the state machine still needs a
terminal state for it — reverting to "cold" plus a failed notification, or setting
openState = "error" with a synthesized code such as local/unexpected. Any of those is better than
an eternal loading.

Paging-side: guarantee that the opening snapshot is bounded. Options, in rough order of
preference:

1. Treat maxMessages as a hard ceiling on the snapshot, not only on the message count — i.e.
   also break when the accumulated page exceeds a byte or record budget.
2. Make turnWindow degrade: if the loop reaches the start of the log without satisfying
   minTurns and the page exceeds maxMessages, cut at the maxMessages boundary instead of
   returning everything.
3. Let minTurns be satisfied by the partial turn at the head of the log (there is exactly one
   turn here, so "turns crossed" is 1 and can never reach 2 regardless of how far back we walk).

Also worth a look: the maxMessages counter uses 156 messages to describe a 1,017-event,
3.93 MB snapshot. Even in a multi-turn session, injected runtime-context / system-reminder /
time-context events do not count toward maxMessages, so the cap measures something quite
different from what a reader of the option name expects.

Relevant code locations

All offsets are byte offsets into resources/app.asar of Desktop 0.2.1-rc.3:

• paginate — ~19,795,542 (same module as ApiSessionController)
• sourceFor — ~19,790,957
• opening snapshot construction — ~19,789,066
• Session.doOpen — ~19,658,166
• Session class — ~19,640,266
• HISTORY_PAGE_OPTIONS — ~19,639,594
• assertSessionWireEvent — ~19,574,631
• remoteErrorOf / isRemoteFailure — ~17,780,668
• MESSAGE_TYPES$1 / DEFAULT_MAX_MESSAGES — ~19,864,252
• chat.loadingHistory / chat.loadError — ~23,845,300 / ~23,620,761 (zh) / ~23,630,016 (en)

Impact

A session that is merely long and single-turn becomes permanently unopenable through the UI, and
the failure mode presents as "still working" rather than "broken". For affected users the content is
only recoverable by reading the session file directly. In my case this blocked access to a session
I needed for follow-up work, and the misdiagnosis cost was significant — the silent loading state
pointed every diagnostic attempt at data corruption, size, plugins, and the Electron profile
directory before the paging logic was found.
会话 id（session-6fc6e014-cfcd-401a-af89-34b900b32841）
/sessions///session.v4.jsonl.zstd

DSH-issue-载入历史永久卡住.md

在折腾插件的时候卡死了，花了3个小时修好，deepseek自己建议发一份issue，算是代发

[dgesteves]

The silent part is two swallows, not one, and it's the same bug as #9639 (reported on 10-13 with a tested patch). It's unchanged in 0.2.1-rc.5 and on master ce7073d.

1. doOpen rethrows anything that isn't a remote failure before it touches openState (session.ts L616-L643).
2. That rejection goes to the session reference's readiness promise, which is muted with void this.ready.catch(() => {}) (service.ts L193), and the main view never awaits it (navigation.ts L507). So it never even shows up as an unhandled rejection, which is why the console stays empty.

On paging: cut = 0, hasMore = false is how every one-turn session with fewer than 500 messages opens, including every new chat (history.ts L392-L427). What's unusual is that this is the only session in your workspace whose opening window starts at seq 0, and that window is 4 MB. Your analysis doesn't show yet which of those two the client actually fails on, because the swallow above hides the error.

To see the real exception on rc.3: F12 opens DevTools in the packaged app (main.ts L979-L981). In Sources, turn on "Pause on caught exceptions", click the session, and resume past any unrelated pauses until it stops in session-controller code. That message and stack are what #9639 and a paging fix need.

There's no setting to work around it in the meantime: the opening page is the constant HISTORY_PAGE_OPTIONS (session.ts L54), not config.

I copied paginate from rc.3 and ran it on synthetic logs. A 2-message chat and a one-turn log with your message counts both open at seq 0 with hasMore: false. The same history split over two turns cuts at the first turn/start with hasMore: true. Everything else here comes from reading the rc.3 source (1f81c04); I didn't run Desktop.

[Katharsis-I]

DSH-renderer-main-thread-freeze-on-session-open.md
README.md
session1.v4.md jsonl.zstd
by my deepseek（My coding skills have effectively vanished.I can't help any more,sorry.）

[dgesteves]

@Katharsis-I Thanks, the frozen console settles it: the two swallows I pointed at can't be what holds this session. Nothing gets to reject while the main thread is busy.

I opened your exact file in the stock client: rc.5 source (b830ec9), the repo's web e2e scaffold (real Host, stock client plugins, Chromium 149). All 576 event frames were byte-for-byte; I only replaced the header frame's cwd, because a C:\ path isn't absolute on macOS and the store rejects it (validation.ts L41-L42).

It opened normally. "Loading history…" showed for about 0.35 s, then the whole turn rendered, ending with the "Task stopped" row. Open took 465 to 474 ms over two runs, the longest main-thread task was 216 ms, and 1+1 kept answering. With CPU throttled 6x: 2.2 s, longest task 1.4 s. A reload that restores it as the current session and the Trajectory tab were fine too.

The interrupted ending does take a special path, but a small one: the turn stays expanded (turn-process.ts L48-L58) and gets one failure row (turn-error.ts L36-L51). Rewriting it to completed changed the page by one DOM node.

reconcile() can't loop on its own either. Empty or backwards candidates are rejected (L170-L174) and the cursor only moves forward (L96-L110). The only unbounded call is a rule's own match() (L157), which plugins supply.

That points at your third-party plugins. #11283 had the same symptoms and turned out to be a plugin's DOM observer loop. Your session text also mentions ten local client patches to lookatstudy 0.26.3.

To find which one:

1. Quit DSH completely, tray included. A second launch quits while the first is alive (single-instance.ts L20-L23).
2. Start it with --remote-debugging-port=9222, attach from chrome://inspect before opening the session, open it, and press Pause in Sources once it freezes. The paused stack shows whose code is running. If the packaged app ignores the flag, use option 3.
3. Or A/B: disable all 11 third-party plugins, restart, open the session, then re-enable them in halves, lookatstudy first.

Run vs read: I ran the stock web client on your file; I didn't run Desktop or your plugins, and the rest is from reading rc.5.

[Katharsis-I]

Confirmed: disabling lookatstudy fixes it.

profile bundles 15 → 14 (removed dsh-plugin-lookatstudy, the other 11
third-party plugins unchanged), restarted, then opened the same session.
It opens normally now. The session file is untouched (1,233,828 B,
same mtime).

For the record: the ten local client patches were never actually applied —
both lib/client.js and lib/index.mjs still have mtime 2026-10-29 21:12:30
(the 0.27.0 install time), so this is stock 0.27.0.

The session opens at cut=0 — 1016 events, 147 assistant messages, 67 code
blocks all in one page. My read is that mountStudyShell's
MutationObserver.observe(doc.body, { childList: true, subtree: true })
plus the full-document querySelector calls in placeRow()/ensureView()
turns rendering into observer-callback backlog on a page that large.
I don't have a call stack, so that last part is inference from the code.

Version: 0.2.1-rc.5, same as your test.
Thank you very much for your guidance and assistance

[dgesteves]

@Katharsis-I Great, thanks for testing it and for checking the patch mtimes. Your read of mountStudyShell sounds right to me: a subtree: true observer on body that runs full-document querySelector calls on every mutation gets very expensive when 1016 events render in one page. That's worth an issue on the lookatstudy plugin with the session size, so the author can scope the observer to the chat container or debounce it.

If this solved it for you, could you mark the answer above? Then the next person stuck on "Loading history…" with third-party plugins can find it quickly.