Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
After updating to OpenClaw v2026.4.29, the gateway process consumes 47-100% CPU continuously, causing severe event loop delays (up to 22 seconds) and breaking Discord integration.
Steps to reproduce
- Update to OpenClaw v2026.4.29
- Have Discord channel sessions active
- Observe CPU spike and stuck session warnings in logs
- Discord inbound stops working
Expected behavior
- CPU usage: <10% idle
- Event loop delay: <100ms
- Discord: Messages work bidirectionally
- Sessions: Clean up properly after processing
Actual behavior
- CPU: 47-100% continuous
- Event loop: 2-22 second delays
- Discord: Outbound works, inbound broken (timeouts)
- Sessions: Stuck in processing state, diagnostic loop spam
OpenClaw version
2026.4.29
Operating system
Ubuntu (VirtualBox VM)
Install method
No response
Model
.
Provider / routing chain
.
Additional provider/model setup details
No response
Logs, screenshots, and evidence
## Log Snippets
liveness warning: reasons=event_loop_delay interval=32s
eventLoopDelayP99Ms=16458.4 eventLoopUtilization=1 cpuCoreRatio=1.034
fetch timeout reached; aborting operation
url=https://discord.com/api/v10/users/@me elapsedMs=20872
Impact and severity
High - Breaks Discord integration, renders system unusable on limited resources.
Additional information
Environment
- Version: 2026.4.29 (d11e02136d2b)
- OS: Ubuntu (VirtualBox VM)
- CPU: 3 cores
- RAM: 5.4 GB
- Node: v22.22.2
Regression Confirmation
- Previous version: Worked fine before 2026.4.29
- Discord worked: Yes, before update
- CPU usage: Normal before update
Symptoms
- High CPU: 47-100% continuous usage by openclaw process
- Event loop delays: 2-22 seconds (should be <100ms)
- Discord broken: Inbound messages don't work, API calls timeout after 20+ seconds
- Slow responses: All API calls 10-100x slower than normal
Root Cause Identified
Stuck session detection/recovery loop spam:
stuck session: sessionId=main sessionKey=agent:main:discord:channel:[MASKED]
state=processing age=123s queueDepth=1 reason=processing_with_queued_work recovery=checking
stuck session recovery skipped: reason=active_embedded_run action=observe_only
sessionId=main age=153s queueDepth=1 activeSessionId=[MASKED]
This repeats every 30 seconds, consuming CPU cycles and filling logs.
Technical Details
- Session stuck in
processing state for 200+ seconds
- Diagnostic system continuously polls stuck sessions
- File lock held:
[MASKED_SESSION].jsonl.lock
- 17 threads active (reasonable, not a leak)
- 303 session files in directory (782MB total)
Thread Breakdown
- 6x tokio-runtime-w (Rust/WASM workers)
- 5x node (Node.js threads)
- 4x libuv-worker
- 1x DelayedTaskScheduler
- 1x openclaw main
Affected Channel
- Discord channel (debug-yourself) — IDs masked for privacy
Workarounds Attempted
- ✅ Cleared session lock files
- ✅ Gateway restart
- ✅ Session directory cleanup
- ✅ Downgrade to v2026.4.14 (confirmed working)
Related Issues
- Discord Gateway timeout:
fetch timeout reached; aborting operation (20s)
- API calls timing out:
sessions.list taking 6+ seconds
Bug type
Regression (worked before, now fails)
Beta release blocker
No
Summary
After updating to OpenClaw v2026.4.29, the gateway process consumes 47-100% CPU continuously, causing severe event loop delays (up to 22 seconds) and breaking Discord integration.
Steps to reproduce
Expected behavior
Actual behavior
OpenClaw version
2026.4.29
Operating system
Ubuntu (VirtualBox VM)
Install method
No response
Model
.
Provider / routing chain
.
Additional provider/model setup details
No response
Logs, screenshots, and evidence
Impact and severity
High - Breaks Discord integration, renders system unusable on limited resources.
Additional information
Environment
Regression Confirmation
Symptoms
Root Cause Identified
Stuck session detection/recovery loop spam:
This repeats every 30 seconds, consuming CPU cycles and filling logs.
Technical Details
processingstate for 200+ seconds[MASKED_SESSION].jsonl.lockThread Breakdown
Affected Channel
Workarounds Attempted
Related Issues
fetch timeout reached; aborting operation(20s)sessions.listtaking 6+ seconds