openclaw - 💡(How to fix) Fix [Bug]: session websocket events are too chatty during background runs [1 pull requests]

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

The gateway broadcasts both session.message and a message-phase sessions.changed event for the same displayable transcript update, duplicating websocket frames and session snapshots during busy background runs.

Steps to reproduce

1. Start a gateway with a subscribed Control UI/operator websocket client.
2. Run background or agent work that appends displayable transcript messages.
3. Enable/count gateway websocket logs and observe adjacent session.message and sessions.changed events for the same message update.

Expected behavior

A displayable transcript update should send one snapshot-bearing websocket event to operator clients. Non-displayable transcript updates can still send sessions.changed so the session list can refresh without exposing hidden message content.

Actual behavior

In the captured live window, session.message events were followed by targeted message-phase sessions.changed events a few milliseconds later, both with one client and dropIfSlow=true.

OpenClaw version

NOT_ENOUGH_INFO

Operating system

Ubuntu/WSL2

Install method

Live development gateway

Model

NOT_ENOUGH_INFO

Provider / routing chain

NOT_ENOUGH_INFO

Additional provider/model setup details

This is gateway websocket/session event behavior and is not provider-specific.

Logs, screenshots, and evidence

Redaction note: websocket `agent` lines that contained generated text were omitted or summarized; event names, counts, timestamps, client counts, and dropIfSlow flags are preserved.

Window counted: gateway log lines 120-865, approximately 2026-05-21T03:11:06Z through 2026-05-21T03:15:25Z.

total=745
ws=429
sessionMessage=18
sessionsChanged=57
diagnostic=113
memoryCore=13
embedded=72

Representative adjacent duplicate message/update pairs:
238: {"subsystem":"gateway/ws"} event session.message seq=targeted clients=1 targets=1 dropIfSlow=true time=2026-05-21T03:11:24.515+00:00
239: {"subsystem":"gateway/ws"} event sessions.changed seq=targeted clients=1 targets=1 dropIfSlow=true time=2026-05-21T03:11:24.519+00:00

262: {"subsystem":"gateway/ws"} event session.message seq=targeted clients=1 targets=1 dropIfSlow=true time=2026-05-21T03:11:27.919+00:00
263: {"subsystem":"gateway/ws"} event sessions.changed seq=targeted clients=1 targets=1 dropIfSlow=true time=2026-05-21T03:11:27.923+00:00

744: {"subsystem":"gateway/ws"} event session.message seq=targeted clients=1 targets=1 dropIfSlow=true time=2026-05-21T03:14:46.880+00:00
745: {"subsystem":"gateway/ws"} event sessions.changed seq=targeted clients=1 targets=1 dropIfSlow=true time=2026-05-21T03:14:46.883+00:00

Code refs from the investigated checkout:

• src/gateway/server-session-events.ts built one session snapshot and broadcast session.message.
• The same handler then broadcast sessions.changed for the same message update.
• ui/src/ui/app-gateway.ts already applies session.message payloads through the session-list updater.

Impact and severity

Affected: gateway sessions with subscribed operator UI/websocket clients. Severity: Medium-high under load; duplicated session snapshots add avoidable serialization and websocket work. Frequency: Observed repeatedly in one live 2026-05-21 gateway window. Consequence: More gateway CPU and websocket traffic during background/agent activity, when event-loop budget is already constrained.

Additional information

The attached fix keeps sessions.changed for non-displayable transcript updates and stops sending the duplicate message-phase sessions.changed after a displayable session.message broadcast.