[Bug] Every session open / client reconnect re-decodes the session log and retains the decoded copy until V8 heap OOM (~30–90s of UI activity)

[gyje]

Environment

• dsh: 0.1.5-rc.1 and 0.1.5-rc.2 (via npm; dsh web profile, shipped bundles only)
• Node: v24.15.0, Linux x64 (Debian), 3.8 GB RAM
• Access: browser UI over an SSH port-forward

What happens

dsh web boots fine and serves the UI, then the server process dies with a V8 heap OOM after roughly 30–90 seconds of session activity:

FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory

The heap climbs to the V8 default limit (~1.9 GB) and mark-compact cannot reclaim it (1936.9 (1947.6) -> 1935.1 (1942.9) MB). With NODE_OPTIONS=--max-old-space-size=1024 it OOMs in ~28 s; with the default limit in ~83 s. Raising the limit only postpones the crash proportionally.

The trigger is opening/switching sessions in the web UI — or the frontend auto-reconnect re-opening the last session. A stale client that reconnects every ~3 s (e.g. an auto-retrying port-forward with the tab still open) will crash a freshly booted, otherwise idle instance in ~80 s with no human interaction.

Control experiment: an instance whose webserver failed to bind (EADDRINUSE) sits flat at ~383 MB RSS for many minutes — the leak requires a successfully served UI + session loads.

Evidence (V8 sampling heap profile)

Captured with HeapProfiler.startSampling (512 KB interval) during the growth window, ~170 s:

TOTAL sampled: 1122.8MB

== TOP by call frame ==
 1095.1MB consumeEventLine @ @deepseek-ai/dsh-session-persistence-jsonl/lib/index.js
    4.0MB decodeSeqRanges @ @deepseek-ai/dsh-session-format-v1-to-v2/lib/index.js
    3.0MB apply @ @deepseek-ai/dsh-token-meter/lib/index.js
    1.5MB Session @ @deepseek-ai/dsh-session/lib/index.js
    1.0MB _processDelta @ @deepseek-ai/dsh-session/lib/index.js
    ... (noise)

97.5% of all sampled allocation lands in consumeEventLine (the SessionLogScanner path: JSON.parse(line) + restore.decodeRow(decoded) per JSONL row).

The session in question is small (~3.8 MB of JSONL), so a single decode cannot fill the heap — the observed ~35 MB/s sustained allocation rate with net retention implies the log is re-decoded on every session open / reconnect and the decoded copies are retained long enough to ratchet the heap up until OOM.

Reproduction

1. dsh web --no-open in a workspace that has a session with history
2. Open the UI and repeatedly open/switch that session (or keep a reconnecting client polling it)
3. RSS climbs at ~35 MB/s; the process aborts with the OOM above in under 90 s

Expected

Repeated opens of the same session revision should reuse the memoized decode (or release prior decoded copies). The heap should stay flat across open/close cycles.

Notes

• coldLogMemo is bounded (COLD_LOG_MEMO_MAX_ENTRIES = 2), so the retention appears to live in the per-open consumers downstream of decodeStoredLog/scanLog, not in the memo itself.
• dsh-session-persistence-jsonl/lib/index.js is byte-identical between rc.1 and rc.2, so upgrading does not fix it.
• Happy to attach the full sampling profile JSON or test patches against a checkout.

[gyje]

Follow-up with more precise trigger characterization (heap limit 2560 MB, WebSocket heartbeat raised to 20 s via the gateway config override):

1. Idle tab + stable connection = no leak. With the page open and untouched, RSS stayed flat (~1963 MB) for 90+ s; 7 stable connections, zero churn. The earlier ~35 MB/s rate only occurs under a reconnect storm (2 s heartbeat + flaky tunnel path: every reconnect re-opens the last session and retains its decoded copy).

2. Each session open/switch retains one decoded copy that is never reclaimed. Observed discrete RSS bursts (+130 to +250 MB per open) for one ~3.8 MB JSONL session (~1300 events); memory never returns to the prior level — ~300 MB retained per open of that session, ~5 opens → OOM at the raised limit.

3. Control: an instance that failed to bind (EADDRINUSE) sat flat at ~383 MB indefinitely — consistent with the above.

So the retention lives in the per-open consumers of the decoded log (downstream of decodeStoredLog/scanLog), not in a background loop; reconnects merely amplify the open rate. Deployments behind stable networks with small sessions (e.g. nginx-reverse-proxied servers) won't hit the limit in practice, which is why it looks machine-specific.