Skip to content

[Bug]: Telegram providers start twice after SIGUSR1 restart, causing permanent getUpdates 409 conflicts #20893

@bencoremans

Description

@bencoremans

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

  1. Configure two Telegram bots under channels.telegram.accounts
  2. Trigger a restart via config.patch (which auto-restarts) or gateway restart tool
  3. Observe logs: each bot shows "starting provider" twice
  4. 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

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions