Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Telegram inbound message duplication — no dedup on identical webhook deliveries [1 pull requests, 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#59113•Fetched 2026-04-08 02:28:26
View on GitHub
Comments
0
Participants
1
Timeline
3
Reactions
0
Author
plpassist82plpassist82
Participants
plpassist82plpassist82
Timeline (top)
referenced ×2cross-referenced ×1

Inbound Telegram messages are delivered to the agent hundreds of times when the gateway is slow to respond (e.g., due to upstream model rate limits or long processing times). The gateway does not deduplicate identical inbound webhook payloads.

Root Cause

Root Cause Hypothesis

Fix Action

Fixed

PR fix notes

PR #59160: fix(telegram): enable update dedup to prevent webhook retries

Description (problem / solution / changelog)

Summary

Fix Telegram webhook duplication when gateway is slow to respond by enabling existing update deduplication.

Problem

When the OpenClaw gateway is slow to respond (e.g., due to LLM rate limits), Telegram retries webhook deliveries using the same update_id. The Telegram plugin currently processes each retry as a new update, causing:

  • 100–300+ duplicate message ingestions
  • Token waste and inflated costs
  • Context pollution and confused agent behavior

This matches the “inbound deduplication” scenario described in the docs, but the Telegram plugin did not implement the recommended deduplication.

Solution

Reuse the existing createTelegramUpdateDedupe and buildTelegramUpdateKey utilities from bot-updates.ts:

  • Add dedup check at the entry point of handleInboundMessageLike
  • Use Telegram update_id as dedup key (correct for retry detection)
  • In-memory LRU cache with 5 min TTL, no external dependencies

Changes

  • extensions/telegram/src/bot-handlers.runtime.ts
    • Import createTelegramUpdateDedupe, buildTelegramUpdateKey
    • Create updateDedupe instance per bot account
    • Early return for duplicate updates with log

Fixes #59113

Changed files

  • extensions/telegram/src/bot-handlers.runtime.ts (modified, +11/-1)
RAW_BUFFERClick to expand / collapse

Summary

Inbound Telegram messages are delivered to the agent hundreds of times when the gateway is slow to respond (e.g., due to upstream model rate limits or long processing times). The gateway does not deduplicate identical inbound webhook payloads.

Reproduction

  1. Send a message via Telegram when the agent is under load or the model provider is rate-limited
  2. Observe the same message arriving 100-300+ times in a single turn
  3. Each duplicate consumes context/tokens and can trigger retry storms

Evidence

This conversation itself demonstrates the bug:

  • "Claude can be rate limited too" arrived ~300 times
  • "Can you create the GitHub issue?" arrived ~400+ times
  • All duplicates have the same message_id (3290, 3302) and identical content

Root Cause Hypothesis

The Telegram webhook delivers retries when OpenClaw does not respond quickly enough (e.g., 200 OK within timeout). The gateway accepts and processes every copy without checking if:

  1. The message_id was already seen recently
  2. The (sender_id + content + timestamp) tuple is a duplicate

Suggested Fix

Add a short-lived dedup cache (e.g., LRU with 5-minute TTL) keyed on Telegram message_id at the inbound webhook handler. If the message_id was already processed, respond 200 OK immediately without re-queuing.

Related Issues

  • #37702 (outbound dedup after compaction)
  • #39208 (duplicate follow-up messages)
  • #33592 (duplicate outbound replies)

Those are outbound dedup issues. This issue is specifically about inbound webhook deduplication.

Environment

  • OpenClaw 2026.3.28
  • Channel: Telegram (direct chat)
  • Surface: telegram
  • Trigger: model rate limits causing slow responses

Impact

  • Context explosion (hundreds of duplicate user messages in context)
  • Token waste / cost explosion
  • Agent confusion and degraded responses
  • This very bug report required multiple attempts due to the duplication

extent analysis

TL;DR

Implement a short-lived deduplication cache to store recently processed Telegram message IDs and respond with 200 OK immediately if a duplicate message is detected.

Guidance

  • Identify the inbound webhook handler and add a deduplication mechanism using a cache (e.g., LRU) with a 5-minute TTL, keyed on the Telegram message_id.
  • Verify that the cache is properly storing and checking message IDs to prevent duplicate processing.
  • Consider implementing a similar deduplication mechanism for other channels or surfaces to prevent similar issues.
  • Monitor the system after implementing the fix to ensure that duplicate messages are no longer being processed and that the cache is not causing any unintended side effects.

Example

# Pseudo-code example of a simple LRU cache
from functools import lru_cache

@lru_cache(maxsize=1000)  # adjust maxsize based on expected traffic
def process_telegram_message(message_id):
    # Process the message and return 200 OK
    pass

Notes

The provided fix assumes that the message_id is unique and can be used as a reliable key for deduplication. If this is not the case, an alternative deduplication strategy may be needed.

Recommendation

Apply the suggested fix by implementing a short-lived deduplication cache to prevent duplicate processing of inbound Telegram messages. This should help mitigate the issues caused by slow responses and rate limits.

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…
#ssr#cache issue#memory leak#API versioning#request timeout

Still need to ship something?

×6

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

Back to top recommendations

TRENDING