[Bug] sessionQuery.readEvent deep-clones the entire session on every call — reading one event is O(session size), and it locks the whole Host event loop

[Yuuyuko-uu]

中文摘要 —— @deepseek-ai/dsh-session-query 的 readEvent（读一条事件）会走 load() → snapshotLive()，而 snapshotLive 用 structuredClone 深拷贝整个会话的事件数组；随后 _readEvent 只用 events[seq] 加一个小窗口，并且又单独 clone 了一次。于是「读一条」= O(会话大小) 的同步深拷贝。任何在循环里调用它的消费者（实测：第三方插件 dsh-vision-router 2.2.0 的 surface repair）都会退化成 O(N × 会话大小)，把整个 Host 的事件循环占死数十秒到数分钟。
CPU 采样：91.4% 在 structuredClone（10817 个样本）；会话 20.67 MB；单次卡顿约 8.5 分钟。
插件侧的对应报告：ysr666/dsh-vision-router#524

Summary

sessionQuery.readEvent({ sessionId, seq }) is documented and consumed as a bounded single-event read, but on the Host it resolves through SessionCorpus.load(), which for a live session calls snapshotLive(session):

// @deepseek-ai/dsh-session-query/lib/index.js:299
function snapshotLive(session) {
  return {
    header: structuredClone(session.header),
    events: session.snapshotEvents().map((event) => structuredClone(event))   // :303
  };
}

So reading one event deep-clones the entire event array, synchronously.

_readEvent then uses only events[seq] plus a small before/after window — and clones the target again:

// :1209
async _readEvent(sessionId, seq, before, after, signal) {
  const loaded = await this._corpus.load(sessionId, signal);   // :1210 → snapshotLive
  const target = loaded.events[seq];                           // :1212  ← all we need
  const startSeq = SessionSeq(Math.max(0, seq - before));
  const endSeq = SessionSeq(Math.min(loaded.events.length - 1, seq + after));
  const targetSnapshot = snapshotSessionEvent(target);         // :1216  ← cloned again
  const events = loaded.events.slice(startSeq, endSeq + 1).map(...);
}

The full deep clone is pure waste for this call.

Environment

@deepseek-ai/dsh	0.1.5-rc.2
@deepseek-ai/dsh-session-query	0.1.5-rc.2
Node	v24.20.0, Windows 11 x64
Session	session.v3.jsonl.zstd = 20.67 MB

Evidence

CPU profile (≈17 s, 10817 samples)

91.4%  9892  structuredClone  @  node:internal/worker/js_transferable:113
 6.5%   698  (garbage collector)
 0.6%    63  snapshotLive     @  @deepseek-ai/dsh-session-query/lib/index.js:299

Stack (identical across repeated captures during one freeze)

#0 (anonymous)             :303
#1 snapshotLive            dsh-session-query/lib/index.js:303
#2 load                    dsh-session-query/lib/index.js:129
#3 _readEvent              dsh-session-query/lib/index.js:1210
#4 apply                   cordis/lib/index.js:120
#5 readEvent               dsh-session-query/lib/index.js:1207
#6 apply                   cordis/lib/index.js:120
#7 readSessionEvent        dsh-vision-router/lib/dsh-contract-compat.js:65
#8 eventForSurfaceRepair   dsh-vision-router/lib/session-vision-index.js:204
#9 repairGuardStopSurface  dsh-vision-router/lib/session-vision-index.js:290

Impact

Any consumer that calls readEvent once per event — a natural thing to do — becomes O(N × session size), fully synchronous, on the main thread:

• The whole Host stops serving: other sessions, the settings panel, session/cancel, and the reload endpoint all time out, because they are all fetch on the same event loop. The UI stays on "thinking" the entire time.
• Observed: Host CPU pinned at 900–1750 ms/s (≈ one full core) while the session's on-disk log was not written at all (it stayed at 20.67 MB) — i.e. pure computation, not I/O.
• A single freeze lasted ≈ 8.5 minutes. The turn that finally completed then reported 79,385 uncached input tokens (the provider's prompt cache had expired during the stall); the following turn was normal again.
• Cost scales with session size, so small sessions are unaffected and large ones freeze on every turn.

Why this is surprising

The consumer explicitly treats this API as bounded — its wrapper is documented as "the narrow bounded Session event reader", and the v2.2.0 release notes say "bounded asynchronous history reads instead of eager indexing". The implementation is not bounded: the cost is proportional to the whole session, not to the requested window.

Suggested fix

readEvent only needs events[seq] plus a small window, so it should not go through load()/snapshotLive():

1. For a live session, read the event directly — session.eventAt(seq) is an O(1) array index in dsh-session — and slice only the requested window.
2. For a cold session, decode only the frames covering the requested seq range instead of materializing and cloning the full log.

Either way the "read one event" path should be O(window), not O(session).

Related reports (same family: "read one thing, pay for everything")

• Bug: session search crashes with `RangeError: Invalid string length` on large sessions (root cause + fix) #1859 — session-query-sqlite's observeSession serializes the whole event log to compute a fingerprint (RangeError: Invalid string length); a commenter there also flags the whole-list structuredClone cost.
• [Perf] session/list is O(sessions) with no summary cache: 2.5-3.0 s and 59.8 MB of reads for ~7,700 sessions #7142 — session/list is O(sessions) with no summary cache (2.5–3.0 s, 59.8 MB).
• Plugin-side report for the freeze this triggered: [Bug] vision-router 2.2.0 repairToolResultSurface deep-clones entire session on every agent step, causing memory blowup and event-loop freeze on DSH 0.1.5-rc.1 ysr666/dsh-vision-router#524

Notes

• I have the raw capture log (~55 KB, stack + profiler samples) and can attach it if useful.
• Happy to test a patched build.
• Temporary workaround used locally: disable the plugin that calls readEvent in a loop (- id: vision-router / disabled: true in the profile's cordis.patch.yml).

[argszero]

Thanks for the profile and the full stack — the source matches it, and the numbers say something a bit sharper than "one redundant copy". Three precision points, then the minimal fix, then what a consumer can do today and what a plugin can do in the meantime.

1. The cost is the clones, not the array

Session.snapshotEvents() is memoized: this.eventsSnapshot ??= Object.freeze([...this.log]) (packages/core/session/src/index.ts:651). The O(N) shallow copy is paid once per append, not once per read — so the per-call O(session) work in snapshotLive is entirely session.snapshotEvents().map(event => structuredClone(event)) (packages/session-query/session-query/src/corpus.ts:303). Your profile is exactly that: 0.6% of samples in snapshotLive itself, 91.4% inside structuredClone. No part of the cost is the array.

And _readEvent clones the target a second time: snapshotSessionEvent(target) (index.ts:381), which is itself structuredClone (core/session/src/index.ts:194-196), while each neighbor and the header get their own clone (:382-385, :387). So one bounded read of one event pays N clones for the corpus + one for the target + one per neighbor + one for the header, and returns window + 1 events.

2. It is readEvent's route, not load()

_corpus.load has six call sites: readSession:185, listEvents:270, filterEvents:299, readSurface:311, traceEvent:341, readEvent:370. Four of those genuinely need the whole sequence — there, O(session) is not waste, it is the answer. readEvent is the one whose cost is not implied by its contract: its own docstring is "Read one full event plus a bounded raw-log context window" (:350), and the returned value honors that.

So the fix belongs inside _readEvent, and load() should keep its clone: it deliberately promises a detached snapshot ("Load one logical source, preferring a detached live snapshot", corpus.ts:83), and a known live target never consulting persistence is on purpose (:85-86). A bounded read needs neither a detached full sequence nor a second clone of the target.

3. Compatibility with the deprecation note (worth stating in the patch)

Your suggestion 1 — for a live session, read the event directly — is the cheap half, and I think it is compatible with 2026-09-09-deprecate-synchronous-session-event-reads, but the distinction is the whole argument, so it should be in the PR rather than left to be inferred:

• The note's rejected alternative is "Keep synchronous single-event reads while deprecating only full snapshots", and its reason is that restricting result size "does not remove the storage dependency". That is about a synchronous API surface — a consumer-visible guarantee that the sequence is resident.
• readEvent is already async and already has a storage path, so an internal fast path over the resident array adds no guarantee. Keeping the windowed storage path for a cold session is what leaves the note's direction intact — the note itself says "Historical content presented on demand uses explicit asynchronous pagination and progressive loading, with each read limited to the requested window."
• The prohibition on "new aliases or wrappers that expose the same synchronous historical access" is aimed at the sync readers (eventAt/snapshotEvents/ownEvents); quoting it in the PR lets a reviewer judge the distinction instead of guessing at it.

If you rewrite it, four behaviors the current code guarantees have to survive:

• window validation before any load (_readWindow:396, SESSION_QUERY_INVALID_WINDOW);
• SESSION_QUERY_EVENT_NOT_FOUND when the position is absent (:373-377 — note the check is target.seq !== seq, not just undefined);
• clamping to max(0, seq - before) / min(events.length - 1, seq + after) (:379-380);
• inheritedEventCount in the result: snapshotEvents() covers the fork-inherited prefix and ownEvents() is the suffix (core/session/src/index.ts:646-665), so seq is positional over the whole log — a windowed read must keep that split.

4. What a consumer can do today

One listEvents(sessionId) call pays one clone pass for the whole session; a per-event readEvent loop pays N of them for the same records. That is the quadratic term — N reads × N clones — and your capture is its signature: a full core pinned in structuredClone, no I/O, the on-disk log unchanged at 20.67 MB. For a consumer that currently loops, folding from one whole-session read (or debouncing to one read per turn rather than one per event) turns O(N²) clones into O(N), which is the difference between minutes and one pass.

5. Making it attributable in the meantime

Nothing at the plugin layer can fix this: the clone is synchronous inside the call, so no wrapper can queue or preempt it, and the note above prohibits a wrapper that serves history itself. What a plugin can do is make the loop visible — which is the half your report does not have ("no log line anywhere saying who is reading"). I published one for that:

• npm: @argszero/cordis-plugin-session-query-read-guard@0.1.0
• repo: https://github.com/argszero/cordis-plugin-session-query-read-guard

It wraps the six SessionCorpus.load() reads, measures per-session call rate and timing, and reports the loop (or a single slow read) with the session id, its event count — the multiplier the caller is paying — call counts inside and outside the window, cumulative/worst milliseconds, and the caller's own stack frames with the plugin's frames removed. Unmounted, the same per-event pass is silent; that control arm is part of the test suite. Honest boundary: there is no enforcement mode (it cannot stop a read it is blocked by), it reads no session history itself, measurement is scoped to sessions live in ctx.sessions (that is where the clone is paid), and it deliberately does not watch listSessions/filterSessions/traceSession (header clones, O(#sessions)) or readTitle* (borrowed event arrays, batch-shaped by design) — mixing those into the same counters would only dilute the signal.

Mount:

- insert:
    - id: session-query-read-guard
      name: '@argszero/cordis-plugin-session-query-read-guard'

With an empty config it reports a loop at more than 25 calls on one session inside 10s, or any single read at 250ms or above, and the report names the consumer so the cause is a log line instead of a CPU profile. Attaching your raw capture would still be useful for the patch — it would let the fix be judged against the exact call pattern that triggered it, rather than against a loop shape we assume.

[Yuuyuko-uu]

Attaching your raw capture would still be useful for the patch

Here it is — the raw capture from the machine that produced the profile in the original post:

https://gist.github.com/Yuuyuko-uu/0f486be3d2be14e22e4f2353ae6bee5f

What is in it: 16 consecutive freeze captures over ~8.5 minutes. Each capture is (1) a Debugger.pause stack taken from the frozen Host process, then (2) a ~17 s Profiler sample window taken after resuming. The Host was identified by the port it serves (:3080), not by guessing from command lines.

The first capture is the clean one:

#0 (anonymous)                  :303
#1 snapshotLive     dsh-session-query/lib/index.js:303
#2 load                          :129
#3 _readEvent                    :1210
#4 apply           cordis/lib/index.js:120
#5 readEvent                     :1207
#7 readSessionEvent dsh-vision-router/lib/dsh-contract-compat.js:65
#8 eventForSurfaceRepair dsh-vision-router/lib/session-vision-index.js:204
#9 repairGuardStopSurface        :290

CPU, 10817 samples: 91.4% structuredClone, 6.5% GC, 0.6% snapshotLive.

Three things that may matter when judging the patch:

1. The stack is the guard-stop path (repairGuardStopSurface, :290) — not the tool-result one. Both were live in this run, so a fix aimed only at repairToolResultSurface would not have covered what was actually captured here.
2. All 16 captures have the same shape, which matches the cursor-reset recurrence (if (scan.count > nodes.length) scan.count = 0) rather than a single full pass.
3. During the freeze the session's on-disk log was not written at all (it stayed at 20.67 MB), so there is no I/O inside the window — it is pure computation.

Paths in the log are the stock Windows Administrator profile and the npx cache; nothing machine-specific beyond that.

Happy to run a patched build against the same call pattern if that helps.

[argszero]

Thanks — this is the half the thread was missing, and it moves where the fix has to sit.

What the capture reads as

All 16 captures (17:18:16 → 17:26:39) carry the same stack: repairGuardStopSurface (session-vision-index.js:290) → eventForSurfaceRepair (:204) → your readSessionEvent shim (dsh-contract-compat.js:65) → sessionQuery.readEvent → _readEvent (:1210) → load (:129) → snapshotLive (:303) → the closing structuredClone (node:internal/worker/js_transferable:113). Eleven of the sixteen put 91.2–92.4% of a 9.5k–11.8k sample window in that single frame (plus ~1.3–1.4% in a second structuredClone entry); the last five report 4.8–47.8% with the same stack and a similar sample total, so the drop is in the share the 17 s post-resume profiler window happened to catch, not in the call path. Each pause is reported at the 6,000 ms detector threshold (6000–6022 ms), so six seconds is a floor rather than a duration, and the first twelve run ~24 s apart before the later gaps widen.

That confirms the cost decomposition instead of merely arguing it: the freeze is the clone, not the walk, not the events[seq] index, not the window slice. snapshotLive (corpus.ts:302-303) is structuredClone(header) plus snapshotEvents().map(structuredClone) — one full clone pass per call — and _readEvent then clones the target a second time (index.ts:377-385) while still returning structuredClone(loaded.header). It also explains the unmoving on-disk log: the corpus is already in memory, so the whole stall is computation, and the log size is a red herring for timing it.

Your cursor-reset reading is the right one — and it is the same defect, restarted

With if (scan.count > nodes.length) scan.count = 0 the patrol re-walks from event 0 instead of resuming, and since each step is a per-event readEvent, one patrol is N reads of an N-event session: N clone passes for records you already hold. The reset restarts that quadratic pass in full, which is exactly why all sixteen captures have one shape — and why a fix aimed only at repairToolResultSurface would not have covered what was captured here. Nothing is retained between passes, so the reset costs what the first pass cost.

The patch, and the primitive that keeps it small

The windowed read is implementable on an existing seam, not as new design: SessionHandle.read(offset?, length?, options?) (session-persistence/src/handle.ts:83) already takes a range, and cold-read.ts is its only consumer today — it reads the whole log with no offset or length. So a windowed readEvent is: open a read handle, read(max(0, seq - before), before + after + 1), keeping the four invariants the current path already has — SESSION_QUERY_INVALID_WINDOW validated before any load (_readWindow), SESSION_QUERY_EVENT_NOT_FOUND on target.seq !== seq rather than on undefined, the clamping at :379-380, and the inheritedEventCount split, because snapshotEvents() covers the fork-inherited prefix while ownEvents() is the suffix. That drops the per-call clone of the entire sequence while leaving the per-event answer intact, which is the shape the deprecation note asks for ("each read limited to the requested window"). It is a core change on the synchronous historical surface, so whether to spend it there rather than on the async migration is the maintainers' call; what your capture changes is that such a patch can be judged against a real call pattern instead of an assumed loop shape.

What you can do today, inside your own plugin

Fold once per patrol instead of once per event: readSession(sessionId) (or listEvents) pays one clone pass for the whole session, and scanning the returned array afterwards is free by comparison. Keep scan.count across patrols and skip the pass when the session's last seq has not advanced; then a cursor reset re-walks an array you already hold, and the ~24 s period stops costing six seconds each time. readEvent is the sharpest case precisely because its contract is per-event while its cost is per-session — one call is invisible, and only a loop turns it into a Host-wide stall that also blocks settings, session/cancel and the reload endpoint, since those are fetches on the same loop.

Attributability

The guard from my earlier reply (@argszero/cordis-plugin-session-query-read-guard@0.1.0) watches the six SessionCorpus.load() reads and reports the caller's own frames; given this capture it would name dsh-vision-router's repair pass and the event count that pass is paying per call. Unmounted, the same pass is silent — that control arm is part of its test suite. It observes; it cannot queue or preempt a synchronous clone, and it serves no history itself.

Stated plainly: nothing at the plugin layer makes a per-event synchronous read cheaper. If a windowed read on this surface is not something the maintainers want to take, then the fold inside your patrol is the durable answer rather than an interim one.