[Bug] dsh web 100% CPU infinite loop in FrameQueue host->browser event mux

[zzlalala98]

Environment

• Package / version: @deepseek-ai/dsh 0.1.0-rc.6 (npx @deepseek-ai/dsh web); @deepseek-ai/dsh-host-apiproxy 0.1.0-rc.6, @deepseek-ai/dsh-session 0.1.0-rc.6
• OS: macOS 26.5.2
• Node: v24.15.0 (nvm)
• Hardware: Apple M4 (10 cores: 4 performance + 6 efficiency), 16 GB
• Launch: dsh web, listening on http://127.0.0.1:3080

Summary

Twice the dsh web process pinned one core at 100% CPU (168 minutes, then 29 minutes) and the Web UI froze. Both samples show the same main-thread hot path:

Builtins_AsyncGeneratorPrototypeNext → AsyncGeneratorResumeNext
  → Builtins_ArrayShift → FastElementsAccessor::MoveElements → WriteBarrier
  (concurrent with) node::StreamBase::Writev

i.e. an async generator endlessly doing queue.shift() → yield → write to the local WebSocket, with a queue that never empties. The local 127.0.0.1:3080 → browser connection carried 1.3 GB and 1.9 GB in two runs. The second occurrence had no external connection at all (only the local browser), so this is a local event-loop bug, not an LLM-API issue.

Reproduction

Not 100% deterministic, but observed as follows:

1. Start dsh web, open the Web UI, run one or more sessions (agents/tools).
2. CPU stays normal (~0.1%) for a while after start.
3. After some runtime, or after a session is resumed / the browser reconnects, the process suddenly pins one core at 100% and the UI becomes unresponsive; the browser keeps receiving a huge stream of frames.

(Reconnect/resume is the suspected trigger, but we could not yet isolate a minimal repro.)

Impact

• One CPU core saturated for tens of minutes to hours; UI fully frozen.
• Unbounded WebSocket frame traffic to the browser (GB-scale), i.e. the event feed is being re-sent in a tight loop.
• Because the process is stuck forwarding events, sessions are effectively unusable; repeated API spend is a secondary cost while any agent activity is involved.

Root cause analysis

The hot stack matches exactly one server-side construct: the FrameQueue async queue in

packages/host/apiproxy/src/... → built to node_modules/@deepseek-ai/dsh-host-apiproxy/lib/index.js:

// dsh-host-apiproxy/lib/index.js:1152-1185
var FrameQueue = class {
    buffer = [];
    waiter;
    done = false;
    push(item) {
        if (this.done) return;
        this.buffer.push(item);
        this.waiter?.();
    }
    end() { this.done = true; this.waiter?.(); }
    async *iterate(signal, cleanup) {
        const onAbort = () => { this.end(); };
        signal.addEventListener("abort", onAbort, { once: true });
        try {
            while (true) {
                while (this.buffer.length > 0) yield this.buffer.shift(); // <-- line 1173 (ArrayShift hotspot)
                if (this.done || signal.aborted) return;
                await new Promise((resolve) => { this.waiter = resolve; }); // only suspends when the buffer is empty
                this.waiter = void 0;
            }
        } finally {
            signal.removeEventListener("abort", onAbort);
            cleanup();
        }
    }
};

• AsyncGeneratorResumeNext = the generator being resumed by the for await consumer; Builtins_ArrayShift → FastElementsAccessor::MoveElements → WriteBarrier = line 1173 this.buffer.shift() (V8 Array.prototype.shift element move + GC write barrier).
• Each yielded frame is written to the browser WebSocket by the consumer → node::StreamBase::Writev.
• iterate() only ever hits the await at line 1175 when buffer.length === 0. If a producer keeps push()ing, the buffer never empties and the generator spins synchronously (100% CPU) while emitting unbounded frames.

Two streams consume this queue in the same file:

• events.mux (line 3612): forwards per-session events to the browser. Its main producer is (line 3645):

ctx.on("session/event", (session, event) => {
    // ...
    queue.push(frame({
        type: "session/event",
        sessionId: session.id,
        event,
        ...view === void 0 ? {} : { view }
    }));
}),

• events.host (line 3698): forwards session/created, agent/status, domain/changed, and API_REMOTE_FORWARDED_EVENTS.

session/event is emitted by the event-sourced session append in

node_modules/@deepseek-ai/dsh-session/lib/index.js append() (line 1440-1480), which pushes to the session log and then emits "session/event" (line 1472). So the loop is:

session.append() → emit "session/event"
  → events.mux ctx.on("session/event") → queue.push(frame)
  → FrameQueue.iterate() → buffer.shift() → yield
  → for-await consumer → WebSocket.write (StreamBase::Writev) → browser

FrameQueue.iterate() has no backpressure, high-watermark, frame-rate limit, or frame dedup. It relies entirely on the assumption that the buffer will eventually drain. When a producer floods (suspected: session restore/resume re-emitting session/event, or a re-forwarding feedback loop), that assumption breaks and the queue degenerates into a busy loop.

Suggested fix

1. Idle guard in FrameQueue.iterate: after draining the buffer, if it was refilled within the same tick, yield to the event loop (e.g. await new Promise(setImmediate) / queueMicrotask) before continuing, so the loop cannot starve the process.
2. High-watermark / coalescing: cap buffer; when exceeded, coalesce session/event frames per sessionId (or drop oldest). This bounds the WebSocket traffic.
3. Frame dedup by (sessionId, event.seq): never forward the same session-event seq twice — this directly breaks any replay/feedback loop.
4. Rate limiting + observability: log frame type + count + a sample stack when a stream exceeds N frames/sec, to identify the flooding producer in the wild.

Unverified (to be confirmed)

• The exact producer that floods session/event was not fully isolated. The restore/resume path (dsh-session-persistence resume/attachPrepared) and the synthetic-closer repair logic (dsh-session/lib/types/repair.js) are candidates but were not proven to loop.
• It is not yet confirmed whether the flood is (a) unbounded re-emission of the stored log during restore, or (b) a self-sustaining feedback loop (frame → browser → host response → new append).

A focused repro around "resume a large session while the browser is connected" would confirm which producer is responsible.

[aphelioussss-gif]

Independent reproduction on Apple M3, with an open/close A/B test

I can independently reproduce the same hot path on:

• @deepseek-ai/dsh 0.1.0-rc.6
• Node v22.23.1
• macOS 15.7.3 (24G419)
• Apple M3 MacBook Air, 24 GB RAM
• Safari as the local Web UI client

A/B observations

State	dsh web CPU	Browser WebContent CPU	127.0.0.1:3080 client sockets	Result
Web UI open	103–109% sustained	78–116%	several ESTABLISHED connections observed during the incident	CPU sensor rose from about 68°C to about 90°C; UI became extremely slow
All DSH Web UI tabs closed	0–0.3% after the active child workload finished	normal	no established client socket to port 3080	server returned to idle and temperature started falling

The dsh web process remained alive during the close-side measurement. Closing the UI connection was the variable that stopped the sustained load.

A 3-second macOS sample of the server process contained the same signatures reported above:

Builtins_AsyncGeneratorResumeNext
v8::internal::Builtin_ArrayShift
node::StreamBase::Writev

Per-process nettop samples also showed the Node process continuously writing while the UI was connected. The sampled cumulative bytes_out increased from 285,349,097 to 286,103,431 over the short observation window.

I separately identified real CPU-heavy child workloads during the investigation, including short-lived Python checker processes. After those children finished and the Web UI was closed, dsh web settled at 0.3% CPU. This helped separate normal task computation from the Web UI-triggered sustained loop.

Important caveat

This is not yet a clean stock-profile reproduction. The active web profile contains third-party plugins, including dsh-memory and dsh-agent-teams, and the persistence store contains about 196 sessions. I am disclosing this because either plugin activity or a large/busy session may amplify the producer rate.

Five legacy Zstandard session logs had also been reframed to the current one-header-first-frame format before this reproduction. Their decompressed JSONL content was verified byte-for-byte identical before and after reframing, so no event content was rewritten.

Despite that caveat, the open/close A/B result and the sampled ArrayShift → AsyncGeneratorResumeNext → Writev path match this report closely. I also checked the current master implementation of FrameQueue; it still drains with buffer.shift() in the async generator and has no visible queue bound or backpressure mechanism.

If useful, I can run a clean-profile reproduction or an instrumented build that records frame type, sessionId, event sequence, queue depth, and frames per second. That should help identify whether the flooding producer is replay/resume, duplicate subscriptions, or high-frequency live events.