Summary

When a model provider with large max output (e.g., DeepSeek v4 Pro, 384K tokens) returns very long streaming responses, the single-threaded Node.js event loop in the gateway gets starved. Stream chunk processing occupies the event loop without yielding, causing cascading delays across all gateway operations.

Diagnostic Evidence

From a session using deepseek-v4-pro on openclaw v2026.5.28 / Windows 10:

Event loop starvation

[diagnostic] liveness warning: eventLoopDelayP99Ms=2447.4 eventLoopDelayMaxMs=6480.2 eventLoopUtilization=0.987

Normal delay < 50ms; here reached 6.5s at 98.7% utilization.

Fetch timeout delayed by stream processing

[fetch-timeout] fetch timeout after 120000ms (elapsed 207325ms) timer delayed 87325ms

The 120s fetch timeout only fired after 207s — an 87-second delay because the timer callback was stuck behind stream chunk processing.

WebSocket response blocked

[ws] ⇄ res ✓ chat.history 215001ms

Returning chat history took 215 seconds.

Sidecar operations stalled

sidecars.session-locks:12577ms
sidecars.acp.runtime-ready:13793ms
sidecars.acp.identity-reconcile:7168ms

Impact

During these episodes the gateway is effectively unresponsive: timers misfire, WebSocket messages queue up, heartbeat/diagnostic events stall, and chat history responses are delayed by minutes.

Suggested Fix

Offload stream chunk processing to a worker thread, or insert periodic setImmediate / process.nextTick yields during long streaming responses to give the event loop breathing room.