Bug type

Behavior bug (incorrect output/state without crash)

Summary

OpenClaw's Telegram provider produces continuous 409 Conflict: terminated by other getUpdates request errors even with a brand new Telegram bot token and health monitor completely disabled. This indicates an internal polling loop leak, not an external conflict.

Steps to reproduce

1. Create a completely new Telegram bot via @Botfather
2. Configure OpenClaw with new token:

   {
     "channels": {
       "telegram": {
         "enabled": true,
         "botToken": "<NEW_BOT_TOKEN>",
         "dmPolicy": "open"
       }
     },
     "gateway": {
       "channelHealthCheckMinutes": 0
     }
   }

3. Start OpenClaw gateway via Docker Compose
4. Observe logs - conflict appears within 60-120 seconds

Expected behavior

• Fresh bot token should have zero conflicts
• With health monitor disabled, no automatic restarts should occur
• /agents command should return list of bound agents

Actual behavior

• getUpdates conflict starts within 60-120 seconds of container start
• Continuous 409 errors every few seconds with exponential backoff
• Messages to Telegram bot are silently dropped
• /agents command receives no response due to conflict blocking message processing

OpenClaw version

2026.3.13-1 (built from source)

Operating system

Ubuntu 25.10 (Docker container)

Install method

Docker Compose with official docker-setup.sh

Model

openrouter/z-ai/glm-4.5-air:free

Provider / routing chain

OpenRouter (Z.AI), Single model, no fallback chain

Config file / key location

openclaw/openclaw.json

Additional provider/model setup details

• Provider: OpenRouter (openrouter.ai)
• Model: z-ai/glm-4.5-air:free (Z.AI GLM-4.5 Air free tier)
• Authentication: API key via OPENROUTER_API_KEY environment variable
• Agent Configuration: Multiple agents (main, testagent) all using the same model
• Workspace: /home/node/.openclaw/workspace/ (Docker container path)
• Gateway Mode: Local (lan binding, port 18789)
• Health Monitor: Disabled (gateway.channelHealthCheckMinutes: 0)

Logs, screenshots, and evidence

[telegram] starting provider
[telegram] getUpdates conflict: Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running); retrying in 2.09s
[telegram] getUpdates conflict: Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running); retrying in 3.82s
[telegram] getUpdates conflict: Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running); retrying in 6.81s
...

Impact and severity

• High severity - Telegram bot completely non-functional
• Silent failure - No user-visible error, just no responses
• All commands affected - /agents, /status, regular chat all fail
• System instability - Cannot use OpenClaw for production Telegram bots

Additional information

Evidence It's an OpenClaw Bug (Not External)

1. Fresh Telegram bot token - No other instance could be using it
2. Single container running - Verified with docker ps and ps aux
3. Health monitor disabled - Set channelHealthCheckMinutes: 0
4. No systemd services - Checked systemctl and crontab
5. No host processes - Only one openclaw-gateway process visible
6. Webhook cleared - deleteWebhook confirmed no webhook set

Related Issues
This appears to be a recurrence/regression of:

• Telegram provider leaks polling loop on SIGUSR1/graceful restart #31107 - Telegram provider leaks polling loop on SIGUSR1/graceful restart
• 409 Conflict loop when polling multiple Telegram bot accounts simultaneously #43569 - 409 Conflict loop when polling multiple accounts
• [BUG] macOS LaunchAgent + configure wizard creates duplicate gateway process, causing 30+ hour Telegram 409 polling conflict #43628 - macOS LaunchAgent creates duplicate gateway process
  Note: The fix from PR Telegram: stop bot on polling teardown #31141 (merged March 2) does not resolve this issue - the polling loop leak persists.

Workarounds Attempted (None Successful)

1. ✅ Disabled health monitor (channelHealthCheckMinutes: 0)
2. ✅ Used fresh Telegram bot token
3. ✅ Complete container stop/start cycle (not restart)
4. ✅ Cleared webhooks via Telegram API
5. ✅ Built from stable release v2026.3.13-1
6. ✅ Verified single container/process

Additional Context

• Container starts healthy and reports no initial conflicts
• Conflict appears consistently 60-120 seconds after start
• Issue occurs with both minimal configuration and full production config
• Affects single-account setups (not just multi-account)