Description

Bug type

Behavior bug (incorrect output/state without crash)

Summary

On macOS with OpenClaw 2026.4.29, the Telegram provider enters repeated 409 Conflict: terminated by other getUpdates request loops even though only one local openclaw gateway process exists.

Direct Bot API getUpdates works normally when the local OpenClaw gateway is stopped, then starts conflicting again only after OpenClaw restarts. This strongly suggests an internal Telegram polling lifecycle overlap / self-conflict inside OpenClaw rather than an external duplicate poller.

This may be related to or a duplicate of #49822, but this report adds a confirmed macOS reproduction and direct stop/start verification against the Telegram Bot API.

OpenClaw version

OpenClaw 2026.4.29 (a448042)

Operating system

macOS

Environment

• launchd service: ai.openclaw.gateway
• gateway mode: local
• bind mode: lan
• Telegram configured in local config, polling mode, no webhook configured

Steps to reproduce

1. Configure Telegram in OpenClaw with a valid bot token.
2. Start the gateway on macOS via the local launchd service or normal gateway startup.
3. Confirm the provider starts successfully.
4. Wait a few minutes.
5. Observe that Telegram begins returning 409 Conflict: terminated by other getUpdates request.
6. Stop the local OpenClaw gateway.
7. Call the Bot API directly with the same token: curl "https://api.telegram.org/bot<TOKEN>/getUpdates?timeout=1&limit=1"
8. Observe that direct getUpdates works normally while OpenClaw is stopped.
9. Restart only OpenClaw.
10. After a short period, the conflict returns.

Expected behavior

A single local OpenClaw gateway process should maintain exactly one active Telegram long-poll and should not self-conflict with getUpdates.

Actual behavior

OpenClaw starts successfully, then later falls into a repeating conflict/rebuild loop:

[telegram] [diag] polling cycle error reason=getUpdates conflict ...
[telegram] getUpdates conflict: Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running) ...
[telegram] [diag] closing stale transport before rebuild
[telegram] [diag] rebuilding transport for next polling cycle

What I verified

1. Only one local openclaw gateway process exists.
2. Hermes is not the cause; it uses a different Telegram bot token.
3. getWebhookInfo returns an empty webhook URL, so webhook mode is not blocking polling.
4. When the local OpenClaw gateway is stopped, direct Bot API getUpdates immediately works normally.
5. After restarting only OpenClaw, Telegram works briefly and then starts returning 409 Conflict: terminated by other getUpdates request again.
6. This reproduces even after disabling health-monitor restarts.

Direct API evidence

While OpenClaw was stopped, the same token returned:

{"ok":true,"result":[]}

That means the conflict disappears when OpenClaw is not running.

Relevant config facts

I tested with:

{
  gateway: {
    channelHealthCheckMinutes: 0,
  },
  channels: {
    telegram: {
      enabled: true,
      healthMonitor: {
        enabled: false,
      },
    },
  },
}

So this does not appear to be caused by the health monitor repeatedly restarting the channel.

Representative logs

2026-05-02T01:15:55.934+02:00 [telegram] [diag] polling cycle error reason=getUpdates conflict inFlight=0 outcome=ok startedAt=1777677349054 finishedAt=1777677355933 durationMs=6879 offset=1 err=Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running) Another OpenClaw gateway, script, or Telegram poller may be using this bot token; stop the duplicate poller or switch this account to webhook mode.
2026-05-02T01:15:55.934+02:00 [telegram] getUpdates conflict: Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running); Another OpenClaw gateway, script, or Telegram poller may be using this bot token; stop the duplicate poller or switch this account to webhook mode. retrying in 2.06s.
2026-05-02T01:15:59.164+02:00 [telegram] [diag] closing stale transport before rebuild
2026-05-02T01:15:59.164+02:00 [telegram] [diag] rebuilding transport for next polling cycle
2026-05-02T01:16:22.969+02:00 [telegram] [diag] polling cycle error reason=getUpdates conflict inFlight=0 outcome=ok startedAt=1777677359413 finishedAt=1777677382968 durationMs=23555 offset=1 err=Call to 'getUpdates' failed! (409: Conflict: terminated by other getUpdates request; make sure that only one bot instance is running) Another OpenClaw gateway, script, or Telegram poller may be using this bot token; stop the duplicate poller or switch this account to webhook mode.

Why this looks internal to OpenClaw

• No second local process was visible in ps aux.
• Direct API polling succeeds with the same token while OpenClaw is stopped.
• The conflict reappears only after OpenClaw restarts.
• The provider repeatedly rebuilds transport after conflict, but the conflict still comes back.

This pattern is consistent with an internal overlapping long-poll lifecycle / leaked poller rather than user misconfiguration.

Impact

High. Telegram becomes unreliable or unusable on macOS in polling mode, even with a single local gateway service.