Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug] Telegram getUpdates 409 conflict when multiple bot accounts poll from same gateway [1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#59198•Fetched 2026-04-08 02:27:38
View on GitHub
Comments
0
Participants
1
Timeline
0
Reactions
0
Author
mrossitmrossit
Participants
mrossitmrossit

When running a single gateway with multiple Telegram bot accounts (8 in our case), the gateway produces persistent 409 Conflict errors on getUpdates — even though every account has a unique bot token.

Error Message

  • With 1 bot account enabled: zero conflicts
  • With 8 bot accounts enabled: ~2 conflicts/minute (after applying mitigations below)
  • Errors always show offset=0, suggesting the conflicting poll loop does not read the persisted offset
  • Before mitigations, the conflict rate was 30+/minute and came in pairs

Root Cause

These two fixes reduced conflicts from ~30+/min to ~2/min. The remaining conflicts appear to be caused by HTTP connection pooling: all 8 bots poll 149.154.166.110:443 and their long-poll getUpdates requests seem to interfere with each other at the connection/dispatcher level (undici/grammY).

Fix Action

Fix / Workaround

  • With 1 bot account enabled: zero conflicts
  • With 8 bot accounts enabled: ~2 conflicts/minute (after applying mitigations below)
  • Errors always show offset=0, suggesting the conflicting poll loop does not read the persisted offset
  • Before mitigations, the conflict rate was 30+/minute and came in pairs

Mitigations applied (partial fixes)

  1. default account had no enabled: false — it inherited another account's token and created a duplicate polling loop. Adding "enabled": false to the default account cut conflicts roughly in half.
  2. network.autoSelectFamily: false in the channels.telegram config block — eliminated the IPv6→IPv4 fallback (fetch fallback: enabling sticky IPv4-only dispatcher) that caused dual requests during the transition window.
RAW_BUFFERClick to expand / collapse

Description

When running a single gateway with multiple Telegram bot accounts (8 in our case), the gateway produces persistent 409 Conflict errors on getUpdates — even though every account has a unique bot token.

Environment

  • OpenClaw version: 2026.3.31 (213a704)
  • Node.js: 22.22.1
  • OS: Ubuntu Linux (x64)
  • Config: 8 Telegram bot accounts (ada, florence, graunt, ivo, jaque, joe, pretzel, ria), each with a unique botToken and 1:1 agent binding

Steps to reproduce

  1. Configure 2+ Telegram bot accounts in channels.telegram.accounts, each with a distinct botToken
  2. Start the gateway
  3. Observe journal logs: getUpdates conflict: terminated by other getUpdates request

Observed behavior

  • With 1 bot account enabled: zero conflicts
  • With 8 bot accounts enabled: ~2 conflicts/minute (after applying mitigations below)
  • Errors always show offset=0, suggesting the conflicting poll loop does not read the persisted offset
  • Before mitigations, the conflict rate was 30+/minute and came in pairs

Mitigations applied (partial fixes)

  1. default account had no enabled: false — it inherited another account's token and created a duplicate polling loop. Adding "enabled": false to the default account cut conflicts roughly in half.
  2. network.autoSelectFamily: false in the channels.telegram config block — eliminated the IPv6→IPv4 fallback (fetch fallback: enabling sticky IPv4-only dispatcher) that caused dual requests during the transition window.

These two fixes reduced conflicts from ~30+/min to ~2/min. The remaining conflicts appear to be caused by HTTP connection pooling: all 8 bots poll 149.154.166.110:443 and their long-poll getUpdates requests seem to interfere with each other at the connection/dispatcher level (undici/grammY).

Expected behavior

Multiple bot accounts with distinct tokens should poll independently without 409 Conflict errors.

Possible root cause

The gateway appears to share an HTTP connection pool (undici dispatcher) across all Telegram bot accounts. Since all bots target the same Telegram API server (149.154.166.110), HTTP/2 multiplexing or HTTP/1.1 keep-alive connection reuse may cause getUpdates long-poll requests from different bots to collide on the same connection. Each bot account should ideally use its own isolated dispatcher/connection pool.

Additional observations

  • TCP connections to Telegram (ss -tnp): 9 connections for 8 bots (close to 1:1, but not strictly isolated)
  • The streaming: "partial" setting on accounts did not significantly affect conflict rate
  • The default account's update-offset-default.json persisted a botId matching another account (ada), suggesting the default account was silently sharing ada's token

Suggested fix

  • Ensure the default account does not inherit or share tokens from named accounts
  • Create one undici Agent/Pool per Telegram bot account to prevent connection-level interference between independent long-poll sessions

extent analysis

TL;DR

Create a separate undici Agent/Pool for each Telegram bot account to prevent connection-level interference between independent long-poll sessions.

Guidance

  • Review the configuration to ensure the default account does not inherit or share tokens from named accounts.
  • Implement a separate undici Agent/Pool for each Telegram bot account to isolate their connections and prevent interference.
  • Verify that each bot account has a unique botToken and 1:1 agent binding.
  • Monitor the TCP connections to Telegram to ensure a 1:1 correspondence between connections and bot accounts.

Example

// Create a separate undici Agent for each Telegram bot account
const { Agent } = require('undici');
const agents = {};

// Initialize agents for each bot account
Object.keys(botAccounts).forEach((accountName) => {
  agents[accountName] = new Agent();
});

Notes

The provided guidance assumes that the undici library is being used for HTTP requests. If a different library is being used, the approach may vary. Additionally, the example code snippet is a minimal illustration and may require adaptation to the specific use case.

Recommendation

Apply workaround: Create a separate undici Agent/Pool for each Telegram bot account. This approach is recommended because it directly addresses the identified root cause of the issue, which is the shared HTTP connection pool across all Telegram bot accounts.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

FAQ

Expected behavior

Multiple bot accounts with distinct tokens should poll independently without 409 Conflict errors.

#api#permission error#memory optimization#batch processing#GPU compatibility

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING