openclaw - 💡(How to fix) Fix [Bug] Telegram channel halts with 'Bot not initialized' on v2026.5.18 — apparent regression of #81973

Filing as a new issue because #81973 is locked. Suspected regression of that bug — symptoms match exactly, reproduced today on the latest stable v2026.5.18.

Reopen candidate — reproduced on openclaw v2026.5.18 today.

Environment

Symptom

For approximately one hour today, one update on a single named account (agentA) was retried twice per second with the same error this issue describes:

2026-05-20T13:15:52.348-03:00 [telegram] [diag] spooled update <update-id> handler failed; keeping for retry: Bot not initialized! Either call `await bot.init()`, or directly set the `botInfo` option in the `Bot` constructor to specify a known bot info object.

99 of the 100 lines in the log ring buffer were this line. The other three accounts (default, agentB, agentC) were unaffected — only agentA got stuck.

On clean restart

A restart cleared it. The startup log shows the recovery path doing exactly the "discard stale update offset" dance, on all four accounts:

[telegram] Detected legacy update offset for account "default" (was <bot1-offset>, now <bot1-offset>); discarding stale update offset <spool-head-1> and starting fresh.
[telegram] Detected legacy update offset for account "agentA"  (was <bot2-offset>, now <bot2-offset>); discarding stale update offset <spool-head-2> and starting fresh.
[telegram] Detected legacy update offset for account "agentB"  (was <bot3-offset>, now <bot3-offset>); discarding stale update offset <spool-head-3> and starting fresh.
[telegram] Detected legacy update offset for account "agentC"  (was <bot4-offset>, now <bot4-offset>); discarding stale update offset <spool-head-4> and starting fresh.

The stuck update was on agentA; the discarded spool head for agentA was exactly the stuck update's ID + 12 — i.e. ~12 updates had queued behind the poisoned one before the loop locked up.

What the closed fix may have missed

• The was X, now X framing on every account suggests in-memory and persisted offsets agreed at boot, but the on-disk spool head was older — i.e. the spool-replay watermark and the polling offset are tracked independently and drift apart. Worth checking whether the persisted bot-info-*.json is sufficient for recovery when getMe fails on this exact path, or whether the spool replay is gated on a different signal than the fix added.
• The retry loop has no backoff — twice per second forever. A single poisoned update generated roughly 170,000 log lines per 24h. Even if init-ordering can fail in rare edge cases, exponential backoff on the spool drain would mask the symptom in operational metrics.
• It is unclear whether the fix covers the multi-account scenario where one account's init() is slow or fails while sibling accounts succeed; in our case only agentA was stuck and the other three were fine.

Attached for the maintainers

addon-full-log.txt (100 lines) and addon-config-redacted.json available at the user's request. Bot tokens and HA JWT redacted.

Mitigation we applied

Restart of the add-on cleared the loop. The recovery path correctly discarded the stale spool offsets.