session.history fails with "RangeError: Maximum call stack size exceeded" when one message has very large sourceEventSeqs

[yu633]

Environment

• Package: @deepseek-ai/dsh-host-apiproxy@0.1.0-rc.6
• Node.js: v24.18.0
• Platform: Windows

Symptom

Loading a long session's history fails with:

history unavailable for session "<session-id>": RangeError: Maximum call stack size exceeded (internal)

The session becomes unreadable in the web UI (history load always fails), even though the session data itself is valid.

Root cause

In paginate() (compiled at lib/index.js; source in packages/host/apiproxy):

js const groupStart = sources !== void 0 && sources.length > 0 ? Math.min(event.seq, ...sources) // spreads sourceEventSeqs into arguments : event.seq;

A surface-replace �ssistant/message event lists every shadowed chunk seq in sourceEventSeqs. In a large session I inspected, one such event carried 254,780 entries. Spreading that many arguments into Math.min(...) exceeds V8's maximum argument count and throws RangeError: Maximum call stack size exceeded, which the history handler catches and reports as internal ("history unavailable for session ...").

Minimal repro

No session data needed:

js Math.min(0, ...new Array(130000).fill(1)) // RangeError: Maximum call stack size exceeded

Proposed fix

Iterate instead of spreading:

js let groupStart = event.seq; if (sources !== void 0) { for (const source of sources) if (source < groupStart) groupStart = source; }

Verified against the real session: pagination completes without error after this change.

Additional note (separate concern)

For such a message the tail page still contains the whole shadowed range (~319k events / ~70 MB JSON in my case), because pagination counts messages but returns raw event ranges. That is a scalability / response-size issue distinct from this crash and worth tracking separately.

[weijiafu14]

Diagnosis and minimal repro both check out, and the fix is right. What I want to add is that this is one of three open threads describing the same underlying session shape, and one of them is about to touch the exact array that crashes here.

The condition behind all three: a long session whose event log is dominated by assistant/chunk deltas of already-closed messages.

• This thread: one assistant/message carries 254,780 sourceEventSeqs, and spreading them into Math.min(...) blows the argument limit. History becomes permanently unreadable.
• session.history: elide chunks of closed messages — 160x smaller pages on chunk-verbose sessions #4678: someone measured a 50-message page at 38,483 events / 9.0 MB / 4.2 s, of which 99.4% were chunk deltas belonging to messages that had already closed, and proposes eliding them on the history read path.
• [bug] In-memory session log is unbounded (append-only) and compaction never trims it - long/heavy sessions OOM the web process #4722: the same shape on the memory side — an unbounded in-memory log that compaction never trims, ending in a ~4 GB OOM of the web process.

The specific collision worth flagging: @nokkies's suggestion on #4678 is to group by sourceEventSeqs rather than a turn:step key, because paginate already relies on that field — which is this exact line. So whoever implements the elision patch will be writing new code against the same 254,780-entry arrays. Two consequences:

1. The elision patch must iterate, not spread. Your fix should land first, or the elision work reintroduces the crash in a new place with the same signature.
2. Your crash is a lower bound on how bad the sizes get in the wild. session.history: elide chunks of closed messages — 160x smaller pages on chunk-verbose sessions #4678's measurement was one production session; yours proves a quarter-million-entry array is reachable. That is useful evidence for the elision proposal, which currently rests on a single session's numbers.

One thing worth adding to your report. The failure is total and permanent for that session — "the session becomes unreadable in the web UI" — from a display-layer routine. That is the same escalation argued on #4703 for the token-accounting underflow: a defect in something that only exists to show you the conversation should not be able to take the conversation away. Saying that explicitly tends to move a fix's priority more than the RangeError does, because it reframes the bug from "history page errors" to "sessions become unrecoverable as they get long" — which, given that the trigger is session length, means every heavy user reaches it eventually.

Also worth noting for triage: you are on @deepseek-ai/dsh-host-apiproxy@0.1.0-rc.6 while #4678 and #4722 report against 0.1.1-rc.2. Since the same paginate line is cited on both lines, it is presumably unchanged — but stating that explicitly saves whoever picks this up from having to check.

Interest disclosure: I maintain a third-party DSH plugin. apiproxy and the session store are DSH's own components — we do not touch them and could not fix this. This is a cross-thread pointer, not a claim about my own code.

[Jstn-1g]

This exact failure is already fixed on current master; it appears to be a packaged-release lag rather than an unimplemented fix.

• official commit: 5201b84
• source now iterates sourceEventSeqs to compute groupStart instead of spreading into Math.min
• the same commit added paginates a message with many provenance sources without variadic argument expansion

I checked the exact current master head (b150a551b8d) and independently ran packages/host/apiproxy/tests/api-proxy-view.spec.ts: 6/6 pass. The regression deliberately makes variadic Math.min reject, so it covers the mechanism in this report.

That means a new reference patch would only duplicate upstream work. The useful next verification is whether the first release containing 5201b84863e restores the affected real session; the separate 70 MB/raw-range scalability issue remains open and is not fixed by this loop change.