openclaw - 💡(How to fix) Fix v2026.4.24 bundled channel runtime deps resolve to openclaw-unknown and stall Telegram/WhatsApp startup [4 comments, 4 participants]

Summary

After upgrading a Docker-based gateway from 2026.4.20 to 2026.4.24, Telegram and WhatsApp channels do not start promptly after gateway readiness. The gateway is HTTP healthy and reports sidecar startup, but channel provider handoff is delayed for ~19 minutes and appears to happen only after the health monitor observes the accounts as stopped.

There is also a reproducible bundled runtime-deps cache split: runtime deps are prepared under both an openclaw-2026.4.24-* root and an openclaw-unknown-* root. The unknown root contains Telegram/WhatsApp/QQBot runtime deps, suggesting one channel/runtime-deps path is resolving the package version as unknown.

Environment

• Version: 2026.4.24
• Runtime: Docker container, Windows 11 host-mounted state directory
• Upgrade path: 2026.4.20 -> 2026.4.24
• Enabled relevant plugins/channels: Telegram, WhatsApp

Observed timeline

Filtered and sanitized log excerpt from one boot:

2026-04-26T12:25:28.378+05:30 [plugins] whatsapp installed bundled runtime deps in 119466ms: @whiskeysockets/[email protected], jimp@^1.6.1
2026-04-26T12:27:34.672+05:30 [health-monitor] started (interval: 600s, startup-grace: 60s, channel-connect-grace: 120s)
2026-04-26T12:27:35.295+05:30 [gateway] ready (12 plugins: acpx, active-memory, bonjour, browser, device-pair, memory-core, memory-wiki, phone-control, talk-voice, telegram, webhooks, whatsapp; 569.7s)
2026-04-26T12:27:35.316+05:30 [gateway] starting channels and sidecars...
2026-04-26T12:46:49.246+05:30 [health-monitor] [telegram:account-a] health-monitor: restarting (reason: stopped)
2026-04-26T12:46:49.296+05:30 [health-monitor] [telegram:account-b] health-monitor: restarting (reason: stopped)
2026-04-26T12:46:49.350+05:30 [health-monitor] [whatsapp:account-a] health-monitor: restarting (reason: stopped)
2026-04-26T12:50:13.826+05:30 [telegram] [account-a] starting provider
2026-04-26T12:50:16.312+05:30 [telegram] [account-b] starting provider
2026-04-26T13:02:47.890+05:30 [whatsapp] [account-a] starting provider (+<redacted>)

This pattern was observed across multiple boots, including after deleting/renaming the previous runtime-deps cache and allowing it to recreate from scratch.

Expected behavior

After [gateway] starting channels and sidecars..., configured Telegram and WhatsApp providers should either start promptly or log a startup failure. Provider startup should not silently stall for ~19 minutes before the first [telegram] starting provider / [whatsapp] starting provider log.

Actual behavior

The gateway reaches readiness, starts sidecars, then channel provider startup is silent for many minutes. The health monitor later reports configured channel accounts as stopped and attempts restart. Provider logs appear only after that long delay.

Network checks performed

Container egress does not appear to be the root cause:

docker exec openclaw-gateway wget -q -O- --timeout=10 https://api.telegram.org
# returned Telegram HTML successfully

docker exec openclaw-gateway node -e "fetch('https://api.telegram.org/botINVALID/getMe').then(async r=>console.log(r.status, await r.text())).catch(e=>console.error(e.name, e.message, e.cause || ''))"
# 404 {"ok":false,"error_code":404,"description":"Not Found"}

docker exec openclaw-gateway node -e "const WebSocket=require('ws'); const timer=setTimeout(()=>{console.log('TIMEOUT'); process.exit(2)},15000); const ws=new WebSocket('wss://web.whatsapp.com/ws/chat'); ws.on('open',()=>{console.log('OPEN'); clearTimeout(timer); ws.close(); process.exit(0)}); ws.on('error',e=>{console.error('ERROR', e.message); clearTimeout(timer); process.exit(1)})"
# OPEN

Runtime-deps cache evidence

After a fresh cache recreation, both roots exist:

/home/node/.openclaw/plugin-runtime-deps/openclaw-2026.4.24-f53b52ad6d21
/home/node/.openclaw/plugin-runtime-deps/openclaw-unknown-1a3ee78ac449

The versioned root contains broad packaged deps, including Telegram/WhatsApp deps. The unknown root also exists and specifically contains channel/runtime deps, including entries such as:

.../openclaw-unknown-1a3ee78ac449/dist/extensions/telegram/package.json
.../openclaw-unknown-1a3ee78ac449/dist/extensions/whatsapp/package.json
.../openclaw-unknown-1a3ee78ac449/dist/extensions/qqbot/package.json
.../openclaw-unknown-1a3ee78ac449/node_modules/grammy/package.json
.../openclaw-unknown-1a3ee78ac449/node_modules/@whiskeysockets/baileys/package.json
.../openclaw-unknown-1a3ee78ac449/node_modules/ws/package.json

Earlier, running a node listing command inside the container also produced an ENOTEMPTY error involving the versioned runtime-deps mirror and the packaged openclaw/plugin-sdk directory.

Suspected cause

A bundled channel/runtime-deps code path appears to resolve the package root from an already mirrored/boundary runtime path. That can land on a stub package boundary whose package metadata has no version, causing the runtime-deps install root to fall back to openclaw-unknown-* even though openclaw --version correctly reports 2026.4.24.

That duplicate/unstable runtime-deps root resolution may be causing the long pre-provider startup stall. The health monitor restart logs appear to be a symptom rather than the cause: startup is already in progress or stuck before provider handoff.

Impact

Telegram and WhatsApp channels are effectively unavailable after boot for a long period and then enter restart/error loops. The gateway itself remains HTTP healthy, which makes this hard to diagnose from health checks alone.