openclaw - 💡(How to fix) Fix 2026.5.22: slow responses / high CPU after upgrade on WSL2, with event-loop delay, timeout warnings, and aborted transport requests

Summary

After upgrading OpenClaw to 2026.5.22, the assistant became noticeably slower to respond and the gateway appears to consume much more CPU than before the upgrade.

The upgrade itself completed successfully and the gateway is fully running on 2026.5.22, but post-upgrade responsiveness degraded.

The strongest signal points to runtime/event-loop starvation inside OpenClaw 2026.5.22, with downstream timeout / abort symptoms.

Environment

• OpenClaw: 2026.5.22
• Host: Linux on WSL2
• Node: 24.14.1
• Gateway mode: local loopback
• Primary channel in use: Telegram

Main symptoms

• noticeably slower replies after upgrade
• apparent high CPU usage by the gateway
• timeout-related warnings in logs
• event-loop delay / liveness warnings
• prompt-build timeouts from active-memory
• transport-level aborted request logs

Verification that upgrade itself completed

After full restart:

• CLI version: 2026.5.22
• gateway version: 2026.5.22
• RPC version: 2026.5.22

So this is not a version mismatch problem anymore.

Relevant logs

Slow startup / warmup

provider auth state pre-warmed in 47321ms eventLoopMax=11685.3ms
provider auth state pre-warmed in 55819ms eventLoopMax=7210.0ms

Event-loop / liveness warnings

liveness warning: reasons=event_loop_delay interval=30s eventLoopDelayP99Ms=1353.7 eventLoopDelayMaxMs=3550.5 eventLoopUtilization=0.867 cpuCoreRatio=0.889
liveness warning: reasons=event_loop_delay,cpu interval=31s eventLoopDelayP99Ms=3695.2 eventLoopDelayMaxMs=8191.5 eventLoopUtilization=0.879 cpuCoreRatio=0.906
liveness warning: reasons=event_loop_delay,event_loop_utilization,cpu interval=30s eventLoopDelayP99Ms=3722.4 eventLoopDelayMaxMs=4521.5 eventLoopUtilization=1 cpuCoreRatio=1.018

Timeout / abort signals

Telegram fetch timeout:

fetch timeout reached; aborting operation
url="https://api.telegram.org/.../getMe"

Telegram fallback warning:

fetch fallback: DNS-resolved IP unreachable; trying alternative Telegram API IP (codes=none, reason=probe timeout/network error)

Timeout with explicit event-loop starvation hint:

fetch timeout reached; aborting operation
timeoutMs=2500
elapsedMs=7502
timerDelayMs=5002
eventLoopDelayHint="timer delayed 5002ms, likely event-loop starvation"
url="https://registry.npmjs.org/openclaw/latest"

active-memory timeout:

[hooks] before_prompt_build handler from active-memory failed: timed out after 15000ms

Aborted transport request:

warn openai-transport {"subsystem":"openai-transport"} [responses] error provider=microsoft-foundry api=openai-responses model=gpt-5.4-mini-openclaw name=Error status=undefined code=undefined type=undefined causeName=undefined causeCode=undefined message=Request was aborted.

This does not look like a normal upstream provider/API failure because status, code, and type are all undefined; it looks more like a client-side abort / timeout side effect.

DNS / Telegram / IPv6 investigation

I specifically tested whether this might be primarily a DNS problem.

Findings:

• DNS resolution for api.telegram.org is healthy
• direct IPv4 TLS connectivity to api.telegram.org is healthy
• host returns both A and AAAA records
• IPv6 is effectively unavailable on this WSL2 host (Network is unreachable)
• there is no usable default IPv6 route

I then tested an IPv4-preference workaround on the host:

precedence ::ffff:0:0/96  100

and restarted the gateway.

Result

This did not fix the main problem.

After the workaround:

• event-loop delay warnings remained
• slow provider-auth prewarm remained
• active-memory prompt-build timeouts remained

So DNS itself does not look like the primary cause. At most, IPv6 / Telegram fallback may be a contributing side issue, but the stronger signal still points to runtime/event-loop starvation inside OpenClaw 2026.5.22.

Current interpretation

This looks most like a performance / responsiveness regression in 2026.5.22, where:

• the gateway falls into heavy event-loop delay / CPU pressure,
• some requests then time out or get aborted,
• transport-level errors like Request was aborted show up as secondary symptoms.

Suspected areas

1. runtime/event-loop starvation after startup or under active load
2. slow provider-auth prewarm path
3. active-memory hook overhead / timeout contribution
4. secondary timeout/abort behavior in transport paths
5. Telegram fallback path as a possible amplifier, but probably not the primary cause