openclaw - 💡(How to fix) Fix Telegram accounts initialized twice on gateway start causing 409 Conflict [2 comments, 2 participants]

Bug: Telegram polling double-initialization causes persistent 409 Conflict

Environment

• OpenClaw version: 2026.5.7 (eeef486)
• OS: Linux 6.17.0-23-generic (x64)
• Setup: 13 Telegram bot accounts configured in a single gateway instance

Description

On every gateway start or restart, the Telegram channel initialization executes in two rounds. Each round starts polling for all configured bot accounts. The first round's pollers are still active when the second round starts, resulting in two concurrent getUpdates pollers per bot token → Telegram returns 409 Conflict: Terminated by other getUpdates request.

Once triggered, the 409 conflicts persist indefinitely and never self-heal.

Evidence

1. Only 1 gateway process running (verified by PID)
2. No external processes (no other machines/processes consuming the same bot tokens)
3. Token uniqueness confirmed — each of the 13 accounts uses its own distinct bot token
4. Every bot shows starting provider exactly 2 times per restart in logs
5. 409 conflicts started from 2026-05-09 18:22 and continued without recovery
6. Manually restarting the gateway reproduces the issue every time

Expected Behavior

Each Telegram bot account should be initialized exactly once on gateway start. The getUpdates long-poll should have exactly one active poller per bot token.

Actual Behavior

Each bot gets two concurrent pollers, causing Telegram to reject one with 409. The conflicts cascade and persist across the lifetime of the gateway process.

Reproduction

1. Configure multiple Telegram bot accounts (observed with 13, likely reproducible with fewer)
2. Start or restart the gateway
3. Observe logs — each bot's provider is started twice
4. Observe 409 Conflict errors from Telegram API

Workaround

None found. The 409 conflicts do not self-resolve even after extended uptime.

Suggested Fix

The Telegram channel initialization path should deduplicate provider starts — likely the startProvider or equivalent method is being called twice per account during the boot sequence. A guard (e.g., tracking active pollers by bot token) would prevent the double initialization.