Summary
Description
After a SIGUSR1 gateway restart (triggered by config.patch or manual restart), each Telegram bot provider starts twice:
[telegram] [default] starting provider (@m*****)
[telegram] [default] starting provider (@m*****) <-- duplicate
[telegram] [r*******] starting provider (@t****)
[telegram] [r*******] starting provider (@t****) <-- duplicate
This causes permanent 409 Conflict errors from the Telegram API:
[telegram] getUpdates conflict: terminated by other getUpdates request;
make sure that only one bot instance is running; retrying in 30s.
Impact
- The conflicts do not self-resolve. In our logs they persist for 20+ minutes (the entire observation window) with two instances alternating every 30 seconds.
- During this period, message delivery is unreliable and delayed.
- Both the default and non-default bots are affected.
Version
2026.2.12 (npm global install, Docker)
Likely cause
The SIGUSR1 restart triggers both a config hot-reload (which restarts the Telegram channel) AND a full gateway restart. This results in two polling loops being started for each bot, and the old ones are never properly terminated.
From the logs:
[reload] config change detected; evaluating reload (...channels.telegram...)
[gateway/channels] restarting telegram channel <-- hot-reload starts new instances
[gateway] signal SIGUSR1 received <-- full restart also starts new instances
[gateway] received SIGUSR1; restarting
Workaround
None known. A full container restart (not SIGUSR1) may help, but we haven't confirmed this.
Environment
- OpenClaw: 2026.2.12
- Node.js: 22.22.0
- OS: Linux (Docker)
- Config: 2 Telegram accounts (default + telegram2)
- Telegram: long-polling (no webhook)
Steps to reproduce
Steps to reproduce
- Configure two Telegram bots under
channels.telegram.accounts
- Trigger a restart via
config.patch (which auto-restarts) or gateway restart tool
- Observe logs: each bot shows "starting provider" twice
- getUpdates 409 conflicts appear immediately and persist indefinitely
Expected behavior
only one bot instance is running
Actual behavior
more than one bot instance trying to run
OpenClaw version
2026.2.12
Operating system
Linux (Docker)
Install method
No response
Logs, screenshots, and evidence
[Thu Feb 19 2026 12:01:06.221]
openclaw-1:
2026-02-19T11:01:06.221Z [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 30s.
Impact and severity
No response
Additional information
No response
Summary
Description
After a SIGUSR1 gateway restart (triggered by
config.patchor manual restart), each Telegram bot provider starts twice:This causes permanent
409 Conflicterrors from the Telegram API:Impact
Version
2026.2.12 (npm global install, Docker)
Likely cause
The SIGUSR1 restart triggers both a config hot-reload (which restarts the Telegram channel) AND a full gateway restart. This results in two polling loops being started for each bot, and the old ones are never properly terminated.
From the logs:
Workaround
None known. A full container restart (not SIGUSR1) may help, but we haven't confirmed this.
Environment
Steps to reproduce
Steps to reproduce
channels.telegram.accountsconfig.patch(which auto-restarts) or gateway restart toolExpected behavior
only one bot instance is running
Actual behavior
more than one bot instance trying to run
OpenClaw version
2026.2.12
Operating system
Linux (Docker)
Install method
No response
Logs, screenshots, and evidence
Impact and severity
No response
Additional information
No response