Description

When running multiple Telegram bot accounts under a single OpenClaw gateway instance, frequent 409 Conflict errors occur on getUpdates calls, causing a restart loop.

Environment

• OpenClaw version: 2026.3.8
• OS: macOS (Darwin, arm64)
• Node: v24.x
• Telegram accounts: 4 bot tokens configured under one gateway

Steps to Reproduce

1. Configure 2+ Telegram bot accounts in openclaw.yaml
2. Start the gateway (openclaw gateway start)
3. Observe logs — 409 Conflict errors appear on getUpdates within minutes

Observed Behavior

• With 1 account active: no 409 errors ✅
• With 2+ accounts active: 409 errors begin ❌
• The health monitor detects "stale socket" (no events for N minutes) → triggers restart → new pollers spawn before old pollers are fully torn down → duplicate getUpdates calls → Telegram returns 409
• This creates a restart loop: 409 → health check restart → 409 → ...
• In our case, we observed 160+ restarts/day before disabling the health monitor

Investigation Details

We performed isolation testing:

• Verified only 1 OS process is running (ps aux)
• Confirmed no webhooks are set (getWebhookInfo clean for all 4 accounts)
• LaunchAgent confirmed not running (no duplicate process)
• Individual curl getUpdates per token works fine when gateway is stopped
• Root cause appears to be: during SIGUSR1 hot-reload (or health-check-triggered restart), previous pollers are not fully cleaned up before new pollers are spawned, creating a race condition where two pollers compete for the same bot token

Current Workaround

Setting channelHealthCheckMinutes: 0 in config disables the health monitor and reduces 409 frequency significantly, but does not fully eliminate the issue during config hot-reloads.

Expected Behavior

• Multiple Telegram bot accounts should coexist without 409 conflicts
• On restart/reload, old pollers should be fully stopped before new ones are created
• Graceful shutdown of polling connections before re-initialization

Suggested Fix

Ensure SIGUSR1 handler (and any restart path) awaits full teardown of existing Telegram pollers (including closing active getUpdates long-poll connections) before initializing new ones. A simple sequence:

1. Signal all active pollers to stop
2. Await confirmation / force-close after timeout
3. Only then create new poller instances