openclaw - 💡(How to fix) Fix [Bug]: Regression after upgrading from 2026.4.23 to 2026.4.26: delayed reply delivery and websocket/control-ui/browser stalls in NAS Docker environment [3 comments, 4 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

After upgrading from OpenClaw 2026.4.23 to 2026.4.26, reply delivery became noticeably slower in my NAS Docker environment.

This does not look like a pure model-inference slowdown or a Slack-only issue. The stronger signal is that internal websocket/control-ui/browser-related requests sometimes stall for tens of seconds, and during those stalls outbound reply delivery becomes delayed.

Slack made the issue easy to observe because Socket Mode logs are explicit, but the underlying problem appears broader than Slack itself.

Steps to reproduce

1. Run OpenClaw 2026.4.26 in the affected NAS Docker environment.
2. Use the gateway normally with active control-ui/websocket/browser paths.
3. Send messages and observe reply latency.
4. Check gateway logs during delayed replies.

Expected behavior

Reply delivery should remain prompt under normal use, without long internal websocket stalls, repeated handshake failures, browser request delays, or channel delivery interruptions.

Actual behavior

Reply delivery becomes slow or inconsistent.

At the same time, logs show:

• very slow internal websocket responses such as node.list taking tens of seconds
• websocket handshake timeout / closed-before-connect events
• webchat/control-ui disconnect/reconnect events
• browser request delays or failures
• outbound delivery delays, with Slack showing the clearest visible symptoms in logs

OpenClaw version

2026.4.26

Operating system

Docker on Synology NAS

Install method

Docker / compose-based NAS deployment

Model

openai-codex/gpt-5.4

Provider / routing chain

Slack DM -> OpenClaw Gateway -> embedded agent runtime -> OpenAI Codex model

Additional provider/model setup details

Relevant active plugin/runtime paths visible in logs:

• slack
• browser
• acpx
• memory-core
• telegram
• talk-voice
• device-pair
• bonjour

Logs, screenshots, and evidence

Relevant log patterns observed during delayed replies:

- ws handshake timeout
- closed before connect
- webchat disconnected code=1006
- node.list 24397ms
- node.list 23778ms
- node.list 79528ms
- browser.request 27813ms errorCode=UNAVAILABLE
- A pong wasn't received from the server before the timeout of 5000ms
- socket disconnected (disconnect). retry 1/12 in 2s
- Failed to send a message as the client has no active connection
- Failed to send a WebSocket message as the client is not ready
- delivered reply only after reconnect/recovery

Impact and severity

his affects normal interactive use because individual replies become noticeably delayed.

Observed impact:

• delayed reply delivery
• unstable websocket/control-ui behavior
• internal request stalls lasting tens of seconds
• downstream channel delivery interruptions during those stalls

Additional information

Why this looks like a regression:

• The same environment/workflow did not show this behavior on 2026.4.23.
• The issue appeared after upgrading to 2026.4.26.
• The strongest correlation is not raw model inference speed, but internal websocket/control-ui/browser-path stalls that coincide with delayed outbound replies.

Current suspicion:

A regression introduced or exposed by 2026.4.26 in the websocket/control-ui/browser path is stalling gateway event processing enough to delay reply delivery across normal use.

Slack is where the delivery problem was easiest to verify from logs, but the root issue does not appear to be Slack-specific.