openclaw - 💡(How to fix) Fix [Bug]: Multi-account Telegram startup — all 16 bots timeout simultaneously, 10s timeout blown to 41-82s with no circuit breaker [1 comments, 2 participants]

Description

When running OpenClaw with 16 Telegram bot accounts, every single bot's getMe health check fails with fetch-timeout during startup. The 10-second timeout is repeatedly blown out to 41-82 seconds elapsed due to event loop starvation — but the root issue here is that the Telegram channel init pipeline lacks any circuit breaker or staggered retry logic for multi-account scenarios.

Environment

• OS: Windows 10.0.26200 (x64)
• Node.js: v25.9.0
• OpenClaw: 2026.5.x
• Telegram bots: 16 concurrent bot accounts

Observed Behavior

All 16 Telegram bots fail getMe during startup:

Log Samples

[fetch-timeout] fetch timeout after 10000ms (elapsed 66668ms)
timer delayed 56668ms, likely event-loop starvation
operation=fetchWithTimeout url=https://api.telegram.org/bot856265...5qhQ/getMe

[fetch-timeout] fetch timeout after 10000ms (elapsed 82339ms)
timer delayed 72339ms, likely event-loop starvation
operation=fetchWithTimeout url=https://api.telegram.org/bot809652...ZAHE/getMe

Chain Reaction

1. All 16 bots fire getMe nearly simultaneously during channels.telegram.start-account
2. Event loop is saturated by synchronous initialization work
3. Timer callbacks are delayed by 56-72 seconds
4. Fetch timeouts fire late (or not at all) because the timer itself was delayed
5. Each timeout generates a WARN log → more I/O → more EL pressure
6. Subsequent operations (session recovery, model prewarm) are further delayed

Relationship to Existing Issues

• #77900 covers a single bot with ENETUNREACH (network offline) lacking circuit breaker
• This issue is about multi-account startup cascade — all 16 accounts timing out simultaneously even when the network is healthy. The root cause is serial initialization + no stagger + no batch-aware retry.

Impact

• Startup time: 2-3+ minutes before all bots either succeed or give up
• User perception: "Gateway started but Telegram not responding" for minutes
• Cascading failure: Event loop starvation from this phase bleeds into all other subsystems
• False alarms: Diagnostic liveness warnings trigger because the ELU stays at 1.0 during startup

Suggested Fix Direction

1. Staggered startup — Add configurable delay between bot account initializations (e.g., 2-3s gap per account)
2. Batch-aware circuit breaker — If >50% of getMe calls fail within a window, pause and back off
3. Worker-thread offload — Move fetchWithTimeout for channel health checks off the main event loop
4. Adaptive timeout — During startup phase, increase timeout to 30s instead of flat 10s
5. Parallel-but-bounded — Limit concurrent getMe calls to N at a time (e.g., 4 concurrent) instead of all 16 simultaneously