openclaw - 💡(How to fix) Fix [Bug]:Gateway event-loop starvation on 2026.5.22 with symptom signature of closed #82773 / #82884, after both fixes shipped

Bug type

Behavior bug (incorrect output/state without crash)

Beta release blocker

No

Summary

On 2026.5.22, the gateway exhibits ~80s event-loop starvation within ~90s of every clean restart, causing Discord gateway READY timeouts and reconnect-backoff loops, even though both #82773 and #82884 fixes are present in this build.

Steps to reproduce

1. Run systemctl --user restart openclaw-gateway on a host running 2026.5.22 with at least one stored session and the codex provider configured.
2. Tail journalctl --user -u openclaw-gateway -f for ~120 seconds after [gateway] ready appears.
3. Observe [fetch-timeout] ... timer delayed Xms, likely event-loop starvation against multiple unrelated URLs, and [discord] gateway READY wait timed out after 15000ms; reconnecting with backoff (attempt 1).

Reproduces 100% of the time on this host.

Expected behavior

NOT_ENOUGH_INFO

Actual behavior

Gateway logs [gateway] ready at startup, then within ~90 seconds the Discord client logs gateway READY wait timed out after 15000ms; reconnecting with backoff (attempt 1). Concurrent fetches to unrelated URLs (discord.com/api/v10/users/@me and registry.npmjs.org/openclaw/latest) both stall simultaneously, with timer delayed 75325ms, likely event-loop starvation and timer delayed 82800ms, likely event-loop starvation respectively. Discord eventually reconnects via backoff, but memory rises from 620MB RSS post-restart to 1.33GB within 30 minutes, approaching the MemoryHigh ceiling.

OpenClaw version

2026.5.22 (a374c3a)

Operating system

Ubuntu 24.04.4 LTS (kernel 6.8.0-111-generic)

Install method

npm global (system-wide, /usr/lib/node_modules/openclaw)

Model

openai-codex/gpt-5.4

Provider / routing chain

openclaw -> google/gemini-2.5-flash -> openai-codex/gpt-5.4 -> claude-sonnet-4-6

Additional provider/model setup details

Embedded codex provider (openai-codex/gpt-5.4) routed via OAuth auth-profile (profiles.openai-codex:<redacted-account>). Throughout the day, this provider repeatedly emits empty response detected ... retrying 1/1 with visible-answer continuation followed by empty response retries exhausted ... surfacing incomplete-turn error. The 2026.5.22 changelog notes "Gateway/models coalesce provider auth-state rewarms after auth-profile failures" — flagging in case the rewarm path after these empty responses is relevant to the stall.

Logs, screenshots, and evidence

Symptom logs (single restart event, redacted user-id):


[discord] client initialized as <bot-app-id>; awaiting gateway readiness
[discord] gateway READY wait timed out after 15000ms; reconnecting with backoff (attempt 1)
[fetch-timeout] fetch timeout after 10000ms (elapsed 85325ms) timer delayed 75325ms, likely event-loop starvation operation=fetchWithTimeout url=https://discord.com/api/v10/users/@me
[fetch-timeout] fetch timeout after 2500ms (elapsed 85300ms) timer delayed 82800ms, likely event-loop starvation operation=fetchWithTimeout url=https://registry.npmjs.org/openclaw/latest


Codex empty-response symptom (recurring throughout the day on Discord agent runs):


[agent/embedded] empty response detected: ... provider=openai-codex/gpt-5.4 — retrying 1/1 with visible-answer continuation
[agent/embedded] empty response retries exhausted: ... provider=openai-codex/gpt-5.4 attempts=1/1 — surfacing incomplete-turn error


Version confirmation:


$ openclaw --version
OpenClaw 2026.5.22 (a374c3a)
$ grep version /usr/lib/node_modules/openclaw/package.json
  "version": "2026.5.22",


Network ruleout (proves it's not transport):


$ curl -m 5 -w "\nhttp=%{http_code} time=%{time_total}s\n" https://discord.com/api/v10/gateway
{"url":"wss://gateway.discord.gg"}
http=200 time=0.139334s


What I ruled out:
- Network: see curl above (200 in 139ms).
- Session count / disk volume: pruned 38 stale sessions on `agent:main` (92 → 54). No change in stall duration.
- Memory pressure: stall is identical at 620MB RSS (post-prune) and 1.4G RSS (pre-prune). Memory regrows to ~1.33G within 30 minutes regardless.
- npm update check: `registry.npmjs.org/openclaw/latest` fetch is a victim — both stalled fetches resolve in the same millisecond when the loop unblocks.

Impact and severity

Affected: single Discord bot on a self-hosted Ubuntu Linux gateway (one host I can speak to directly). Severity: High — Discord channel is unresponsive on every clean restart for 90+ seconds; memory regrows to MemoryHigh ceiling within 30 minutes, requiring periodic intervention. Frequency: Always — 100% reproduction on every clean restart of the gateway. Consequence: Discord messages may be missed or delayed during the reconnect-backoff loop; gateway operations slow gateway-wide during the stall window; sustained memory pressure increases risk of OOM kills.

Additional information

This is filed not as a regression but as a separate bug with the same symptom signature as the closed #82773 and #82884 — both upstream fixes are present in 2026.5.22 (the bounded-worker rework merged 2026-05-17 to milestone v2026.5.18), yet the timer delayed Xms, likely event-loop starvation + Discord READY timeout pattern persists on this build. The implication is a separate code path is doing sync work on the event loop during channel/Discord startup, distinct from the usage.cost/sessions.usage paths that the prior fixes addressed.