session-query: a "bounded" readEvent deep-clones the whole session log — synchronous main-thread stall on large sessions

[netweaver]

Summary

sessionQuery.readEvent() is documented as "one full event plus a bounded raw-log context window".

Internally it calls load(), which structuredClones every event in the log:

// packages/session-query/session-query/src/corpus.ts (current master)
function snapshotLive(session: Session): LogicalSession {
  return {
    header: structuredClone(session.header),
    inheritedEventCount: session.inheritedEventCount,
    events: session.snapshotEvents().map(event => structuredClone(event)),
  }
}

The bound constrains only the returned value, not the work performed. Reading one event costs a deep copy of the entire session log.

structuredClone is synchronous. On a large session this is a multi-second-to-minute main-thread block, during which the host serves no HTTP at all — the whole Web UI (Settings, other sessions, send/stop buttons) stops responding, with no error output anywhere.

Environment

• DSH 0.1.5-rc.2 (workspace install), Node v24.9.0, Windows
• Session shape: 6,732 events / 31.2 MB raw JSON / 118 turns / 1,311 tool/result events

What we observed

After sending one message in that session:

• The entire Web UI stopped responding (not just that session): dynamic Settings lists, other sessions' history, and the send/stop buttons all failed
• No error was printed anywhere — not a crash, just a synchronously occupied CPU
• The only recovery was killing the process; on the next cold load, crash recovery appended turn/end { reason: { kind: "interrupted" } }

Evidence

(1) Call stack at the moment of the stall (captured with Debugger.pause, 10 frames):

 0  (anonymous)
 1  snapshotLive            @ dsh-session-query/lib/index.js:299
 2  load                    @ dsh-session-query/lib/index.js:125
 3  _readEvent              @ dsh-session-query/lib/index.js:1209
 4  apply                   @ cordis/lib/index.js:118
 5  readEvent               @ dsh-session-query/lib/index.js:1202
 6  apply                   @ cordis/lib/index.js:118
 7  readSessionEvent        @ dsh-vision-router/lib/dsh-contract-compat.js:57
 8  eventForSurfaceRepair   @ dsh-vision-router/lib/session-vision-index.js:200
 9  repairToolResultSurface @ dsh-vision-router/lib/session-vision-index.js:247

(2) Self time over a 15-second CPU sample:

  13,820 ms  structuredClone  @ node:internal/worker/js_transferable:112   <- 92%
     893 ms  (garbage collector)
     788 ms  snapshotLive     @ dsh-session-query/lib/index.js:299
     217 ms  structuredClone  @ (no url)

The main thread was 100% saturated for the whole sampling window, 92% of it inside structuredClone.

Root cause

readEvent is supposed to produce one event plus a small window, but the path it takes is:

async readEvent(request, signal) {
  ...
  return this._readEvent(sessionId, seq, before, after, signal);
}

async _readEvent(sessionId, seq, before, after, signal) {
  const loaded = await this._corpus.load(sessionId, signal);   // whole log + full deep clone
  const target = loaded.events[seq];                          // only this one is needed
  ...
}

Note that the same file already contains a non-copying counterpart:

// sourceLive() in the same file: no clone at all
function sourceLive(session: Session): LogicalSessionSource {
  return { header: session.header, events: session.snapshotEvents() }
}

and the persistence layer already uses a freeze-once / share-without-copying model:

The backend deep-freezes each event graph once before memoization, so later handle reads reuse it without copying.

The package documents the cost itself:

Exact reads replay whole logs — readSession, readSurface, filterEvents, and event traces load and validate the complete logical log, so very large histories pay full inspection per call

and this comment shows the migration is known and deferred:

// oxlint-disable-next-line typescript/no-deprecated -- Existing Session history read; migration deferred.

In short: the machinery for avoiding a whole-log copy already exists in this codebase (sourceLive, plus the persistence layer's freeze-and-share). snapshotLive / readEvent is the path that was missed.

Scope beyond a single consumer

The incident was triggered by a third-party plugin that called readEvent once per repaired sequence on agent/pre-step — O(items × logSize), i.e. 1,311 × 31.2 MB. That plugin switched to the session/event feed in its own 2.2.1 and is no longer affected.

But the amplifier described here lives in core and remains reachable: any plugin, tool, or UI path that consumes readEvent / readSession / readSurface / filterEvents against a long session pays a full synchronous deep clone for what is documented as a bounded read.

Suggested changes (by cost/benefit)

1. Share instead of copying. session.snapshotEvents() is already the shareable path sourceLive() uses, and the persistence layer already freezes each event graph once for copy-free reuse. A "detached" result need not be a fresh deep clone — sharing frozen events is enough, or fall back to a lazy / copy-on-write snapshot.
2. Make the bound real. readEvent should not route through load(). It needs one event plus a small window: a slice read on the persistence handle, or the observation path the docs already describe as never copying the log for header/cursor/projection-only consumers. At minimum, a batch of repairs should take one snapshot, not one per item.
3. Bound the synchronous work. Even with 1 and 2, a pathological log can still stall the loop; consider chunking with yields, or a cap per operation.

Reproduction

No private data is required. Any session with a few thousand events and a few hundred tool/result events reproduces this as soon as a consumer calls readEvent once per event. Our instance was 6,732 events / 31.2 MB / 1,311 tool/result events.

Notes

• This post contains no session content. The attached CPU profile carries only function names, module paths (user name and workspace path replaced with placeholders), and sample timing.
• We are not reporting the third-party plugin — it has been fixed on its own side. We are reporting the core cost model it tripped over.

---

Full CPU profile: attached below (sanitized — the user name and workspace path are replaced with <user> / <workspace>; it contains only function names, module paths, and sample timing).

中文版（点击展开）

摘要

sessionQuery.readEvent() 的文档是："one full event plus a bounded raw-log context window"。

但它内部调用 load()，而 load() 会逐个事件 structuredClone 整个日志：

// packages/session-query/session-query/src/corpus.ts（master 分支现状）
function snapshotLive(session: Session): LogicalSession {
  return {
    header: structuredClone(session.header),
    inheritedEventCount: session.inheritedEventCount,
    events: session.snapshotEvents().map(event => structuredClone(event)),
  }
}

也就是说：bounded 只约束了返回给调用方的那一段，没有约束它实际做的工作量。 要一个事件，代价就是一整个会话日志的深拷贝。

structuredClone 是同步的。在大会话上，这是一次几十秒到几分钟的主线程阻塞 —— 期间宿主无法响应任何 HTTP 请求，整个 Web 界面（设置页、其他会话、发送/停止按钮）一起失去响应，且没有任何错误输出。

环境

• DSH 0.1.5-rc.2（工作区安装），Node v24.9.0，Windows
• 会话规模：6,732 个事件 / 31.2 MB 原始 JSON / 118 轮 / 1,311 个 tool/result 事件

现象

在该会话中发送一条消息后：

• 整个 Web UI 失去响应（不只是该会话）—— 设置页的动态列表、切到其他会话的历史、发送/停止按钮全部失效
• 终端没有任何报错（不是崩溃，是 CPU 被同步占住）
• 只能强制结束进程；下次冷加载时崩溃恢复补写了 turn/end { reason: { kind: "interrupted" } }

证据

① 主线程暂停时的调用栈（用 Debugger.pause 抓取，10 帧）：

 0  (anonymous)
 1  snapshotLive            @ dsh-session-query/lib/index.js:299
 2  load                    @ dsh-session-query/lib/index.js:125
 3  _readEvent              @ dsh-session-query/lib/index.js:1209
 4  apply                   @ cordis/lib/index.js:118
 5  readEvent               @ dsh-session-query/lib/index.js:1202
 6  apply                   @ cordis/lib/index.js:118
 7  readSessionEvent        @ dsh-vision-router/lib/dsh-contract-compat.js:57
 8  eventForSurfaceRepair   @ dsh-vision-router/lib/session-vision-index.js:200
 9  repairToolResultSurface @ dsh-vision-router/lib/session-vision-index.js:247

② CPU 采样 15 秒的自身耗时分布：

  13,820 ms  structuredClone  @ node:internal/worker/js_transferable:112   ← 92%
     893 ms  (garbage collector)
     788 ms  snapshotLive     @ dsh-session-query/lib/index.js:299
     217 ms  structuredClone  @ (no url)

主线程在采样窗口内 100% 饱和，92% 花在 structuredClone。

根因

readEvent 的职责是「一个事件 + 一小段窗口」，但它走的路径是：

async readEvent(request, signal) {
  ...
  return this._readEvent(sessionId, seq, before, after, signal);
}

async _readEvent(sessionId, seq, before, after, signal) {
  const loaded = await this._corpus.load(sessionId, signal);   // ← 整日志 + 全量深拷贝
  const target = loaded.events[seq];                          // ← 实际只需要这一个
  ...
}

值得注意的是，同一个文件里已经有一条不拷贝的对照路径：

// 同一文件的 sourceLive()：完全不拷贝
function sourceLive(session: Session): LogicalSessionSource {
  return { header: session.header, events: session.snapshotEvents() }
}

而且持久化层已经采用「冻结一次、之后共享」的模型：

The backend deep-freezes each event graph once before memoization, so later handle reads reuse it without copying.

包文档本身也承认这个代价：

Exact reads replay whole logs — readSession, readSurface, filterEvents, and event traces load and validate the complete logical log, so very large histories pay full inspection per call

而源码里这条注释说明该迁移是已知且被推迟的：

// oxlint-disable-next-line typescript/no-deprecated -- Existing Session history read; migration deferred.

简单说：避免整日志拷贝的机制在这份代码里已经存在（sourceLive + 持久化层的冻结共享），snapshotLive / readEvent 是漏网的那一处。

影响范围不止一个消费者

触发我们这次故障的是一个第三方插件（在 agent/pre-step 上逐条调用 readEvent，复杂度 O(待修条目数 × 日志大小)，即 1,311 × 31.2 MB）。该插件已在自己的 2.2.1 版本改用 session/event 事件流，那一侧已经闭环。

但这里描述的放大器在核心里，且仍可达：任何消费 readEvent / readSession / readSurface / filterEvents 的插件、工具或 UI 路径，只要面对长会话，都会以「一次 bounded 读取」的代价触发一次整日志同步深拷贝。

建议（按性价比排序）

1. 能共享就不要复制。 session.snapshotEvents() 已经是 sourceLive() 使用的可共享路径，持久化层也已经把每个事件图冻结一次供后续无拷贝复用。「detached 结果」未必需要一次全新的深拷贝 —— 共享已冻结的事件即可，或者退一步做惰性/写时复制。
2. 让 bounded 名副其实。 readEvent 不应该经过 load()。它只需要一个事件加一小段窗口：可以走持久化句柄的切片读，也可以走那条文档里写明「header / cursor / 投影类消费者永不拷贝日志」的 observation 路径。最起码，批量修复应当只取一份快照，而不是每条一次。
3. 给同步工作量加上界。 即使做完 1 和 2，极端大的日志仍可能卡住事件循环；可以考虑分片让出、或对单次操作设上限。

复现

不需要任何私有数据。 任何具备「几千个事件 + 几百个 tool/result」的会话，只要有消费者对每个事件各调一次 readEvent，即可复现。我们这次的具体规模是 6,732 个事件 / 31.2 MB / 1,311 个 tool/result。

说明

• 本帖不包含任何会话内容。附带的 CPU profile 仅含函数名、模块路径（用户名与工作区路径已替换为占位符）和采样时序。
• 我们不是在报告那个第三方插件 —— 它已经在自己的版本里修好了。我们报告的是它踩中的核心代价模型。

---

freeze.sanitized.cpuprofile