openclaw - 💡(How to fix) Fix [Bug]: Gateway event-loop starvation causes Discord/session timeouts under cron and tool load

Summary

OpenClaw gateway can become event-loop starved under mixed Discord agent, cron/session maintenance, and tool load. User-visible symptom is Discord thread/session timeouts even while the Discord provider is connected and channels resolve.

This is not the earlier local bind mismatch we saw; current gateway is reachable on loopback and Discord starts correctly.

Environment

• OpenClaw: 2026.5.14-beta.2 on Ada gateway
• Host: Linux 6.8.0-1053-gcp
• Gateway bind: loopback, 127.0.0.1:18789
• Plugins loaded include: discord, codex, telegram, google-meet, voice-call, lossless-claw, memory-core, etc.
• Model/session context: large agent sessions, several Discord sessions at ~272k context tokens

Related but separate repro observed on another host:

• OpenClaw: 2026.5.16-beta.4
• Host class: Raspberry Pi / Linux arm64
• Flow: update/restart, cron forced-run, gateway close / event-loop delay

Impact

• Discord threads appear abandoned or timeout during heavy gateway load.
• Gateway provider remains online, so this is easy to misdiagnose as Discord routing failure.
• Restarts during active sessions interrupt turns and leave sessions in historical timeout status.

Evidence

Recent Ada gateway evidence:

2026-05-18T00:40:37.272Z [gateway] http server listening (... discord ...)
2026-05-18T00:41:21.771Z [discord] [default] starting provider
2026-05-18T00:41:27.784Z [fetch-timeout] fetch timeout after 2500ms (elapsed 4819ms) timer delayed 2319ms, likely event-loop starvation operation=fetchWithTimeout url=https://discord.com/api/v10/oauth2/applications/@me
2026-05-18T00:41:27.792Z [discord] [default] Discord bot probe resolved @SuperAda
2026-05-18T00:41:34.374Z [discord] channels resolved ... (+29)
2026-05-18T01:03:09.630Z [diagnostic] liveness warning: reasons=event_loop_delay ... eventLoopDelayMaxMs=1203.8 ... active=agent:main:discord:channel:...

Gateway probe later recovered:

Local loopback ws://127.0.0.1:18789
  Connect: ok
  Read probe: ok

Host resources were not saturated at the time:

Gateway RSS: ~807MB
CPU: ~12%
System load: <1
Available memory: ~28GiB

Earlier related Pi/beta evidence:

GatewayTransportError: gateway closed (1000 normal closure)
fetch timeout after 10000ms (elapsed 29468ms) timer delayed 19468ms
Discord ws handshake timeout

Repro Shape

1. Run OpenClaw gateway with Discord provider enabled.
2. Have multiple large Discord agent sessions active or recently active.
3. Trigger cron/session maintenance or a forced cron run while agent/tool work is active.
4. Include tool-heavy work such as image generation or embedded Codex app-server streaming.
5. Observe gateway event-loop delay and Discord/session timeouts despite provider startup/channel resolution succeeding.

Expected

• Discord provider health and active thread turns should not be blocked by long-running agent/tool/context maintenance work.
• Gateway should isolate or queue heavy work without starving timers, Discord probes, or session IO.
• Gateway restarts should not leave active Discord work in ambiguous timeout states without recovery guidance.

Actual

• Timers are delayed by seconds to tens of seconds.
• Discord API probe/fetch can timeout even though the bot resolves immediately afterward.
• Session turns timeout or are interrupted by gateway restarts.
• Gateway can close WebSocket connections with 1000 normal closure during forced cron/restart paths.

Notes

This may relate to existing event-loop/gateway-load issues, but this report adds Discord/session timeout impact and recent beta evidence. The actionable root appears to be per-process event-loop starvation / lack of workload isolation rather than Discord connectivity itself.