Bug

Version: v2026.3.28

Problem

The openclaw-control-ui webchat client polls sessions.list every ~5-7 seconds per connected tab. With a large LCM database (~5,000 conversations, 163K messages), each sessions.list call takes ~4.8 seconds to resolve.

Two open tabs (overview + chat) produce ~24 calls/minute, keeping the gateway at 100% CPU permanently. This blocks other operations — agent spawns time out at 10 seconds because the gateway cannot service them between sessions.list responses.

Observed Impact

• Gateway pegged at 100% CPU, 3.8 GB RSS
• sessions.spawn calls timeout (10s) — unable to run concurrent sub-agents
• Previously could run 10 parallel agents; now struggles with 2
• Closing both webchat tabs immediately dropped CPU to ~20%

Gateway log evidence

sessions.list 4799ms conn=96c962a9…a738
sessions.list 4783ms conn=96c962a9…a738
sessions.list 4786ms conn=e6d28eb7…db0c
sessions.list 4780ms conn=96c962a9…a738
sessions.list 4765ms conn=e6d28eb7…db0c

Two connections (96c962a9 = overview tab, e6d28eb7 = chat tab), both identified as openclaw-control-ui webchat v2026.3.28.

Root Causes

1. No pagination/caching on sessions.list — appears to do a full scan of all conversations every call. 4.8s is too slow regardless of polling frequency.
2. Aggressive polling interval — ~5s per tab with no backoff, no document.hidden check, no debouncing across multiple tabs.

Suggested Fixes

Server-side:

• Cache sessions.list results (TTL 10-30s) — session list changes rarely
• Add pagination support (offset/limit)
• Consider a lightweight /sessions/summary endpoint that returns counts + last-active without full enumeration

Client-side:

• Increase polling interval to 15-30s (sessions change slowly)
• Pause polling when tab is not visible (document.visibilitychange)
• Deduplicate across tabs (SharedWorker, BroadcastChannel, or localStorage lock)
• Use exponential backoff if response time exceeds threshold

Environment

• macOS (arm64), Node v22.22.1
• LCM DB: 1.0 GB, 5,082 conversations, 163,059 messages, 1,204 depth-0 summaries
• Gateway bound to loopback (127.0.0.1:18789)