openclaw - 💡(How to fix) Fix HTTP server becomes unresponsive while WebSocket continues working (event loop blocking) [2 comments, 2 participants]

Summary

After upgrading to OpenClaw 2026.5.3, the gateway HTTP server silently stops responding to inbound requests (e.g., BlueBubbles webhook POSTs) while the WebSocket server continues functioning normally. This causes all webhook-based channels to stop receiving messages with no error logged.

Environment

• OpenClaw 2026.5.3-1 (2eae30e)
• Node v25.8.2
• macOS 26.4.1 (arm64, Mac mini)
• @openclaw/bluebubbles 2026.5.3
• Gateway port: 18789 (HTTP + WS on same port)

Reproduction

The issue reproduces consistently within 30-60 minutes of a fresh gateway start. It has occurred 4+ times today.

1. Gateway starts normally, HTTP server listening, BlueBubbles webhook registered
2. After 30-60 min, HTTP POST requests to the webhook endpoint get no response (curl shows "Received HTTP/0.9 when not allowed" or empty response; netcat gets binary WebSocket upgrade bytes instead of HTTP)
3. WebSocket connections remain fully functional (Control UI works fine)
4. No errors in gateway.log — the HTTP server just silently stops processing requests
5. Only fix is a full openclaw gateway restart

Diagnostics

The verbose log shows event loop blocking coinciding with the failures:

[diagnostic] liveness warning: reasons=event_loop_delay interval=30s eventLoopDelayP99Ms=152.7 eventLoopDelayMaxMs=2424.3 eventLoopUtilization=0.33 cpuCoreRatio=0.376 active=1 waiting=0 queued=2

Max event loop delay of 2.4 seconds means the HTTP server cannot process incoming connections while the event loop is blocked.

Additionally, there are multiple fetch-timeout warnings (5000ms timeouts on external fetches) suggesting heavy I/O contention.

Timeline (2026-05-04)

• 11:31 AM — Gateway restart after update. BlueBubbles working.
• ~1:15 PM — HTTP server dies silently. No webhooks received. WS still fine. No errors logged.
• 1:15 PM — Manual restart fixes it. Catchup replays missed messages.
• ~7:44 PM — Restart. Working again.
• ~8:16 PM — Dead again (32 min). Watchdog cron detects and restarts.
• ~8:19 PM — Restart. Working again.
• ~8:19 PM — Dead again almost immediately after restart.

Workaround

Running a cron watchdog that pings the HTTP endpoint every 5 minutes and issues openclaw gateway restart when unresponsive. This limits message loss but is not a real fix.

Suspected Cause

The gateway appears to share HTTP and WebSocket on the same port (18789). When the Node.js event loop blocks (from embedded agent runs, cron job execution, or model calls), the HTTP request handler becomes unresponsive while established WebSocket connections survive due to their persistent nature.

This may be a regression in 2026.5.3 — the issue was not observed before the upgrade (previously on 2026.5.2).

Expected Behavior

The HTTP server should remain responsive to webhook POSTs regardless of agent/cron workload, or the gateway should detect and self-heal when the HTTP listener becomes unresponsive.