Issue Station
Sign In
Tools hereToolbox

openclaw - 💡(How to fix) Fix [Bug]: Telegram partial streaming mode causes duplicate reply batches [1 comments, 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#75830•Fetched 2026-05-02 05:29:24
View on GitHub
Comments
1
Participants
1
Timeline
2
Reactions
2
Author
usimicusimic
Participants
usimicusimic
Timeline (top)
closed ×1commented ×1

Setting channels.telegram.streaming.mode to "partial" causes every reply batch to be sent twice. The entire group of messages repeats — not individual message duplication, but the whole reply batch arrives, then arrives again.

This happens regardless of TTS being on or off. With TTS on, you get: text message + text+audio message. With TTS off: two identical text messages. The pattern is consistent — the second batch arrives as a group, right after the first.

Root Cause

The partial streaming mode sends a preview message (edited incrementally as tokens arrive) and then a final delivery. When the final delivery does not properly replace/supersede the preview, both the preview content and the final content appear as separate deliveries — resulting in the entire reply batch appearing twice.

This is likely related to PR #39429 (which addresses TTS-specific duplication via didSendViaTtsTool), but the bug is broader: it affects any reply in partial mode, not just TTS payloads.

Fix Action

Workaround

Setting channels.telegram.streaming.mode to "block" eliminates the duplication completely, including with TTS enabled. You still get typing indicators during tool execution and chunked code-block delivery, just no per-token streaming.

"off" also works but kills the typing indicator entirely.

{
  "channels": {
    "telegram": {
      "streaming": {
        "mode": "block"
      }
    }
  }
}

Code Example

{
  "channels": {
    "telegram": {
      "streaming": {
        "mode": "block"
      }
    }
  }
}
RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Summary

Setting channels.telegram.streaming.mode to "partial" causes every reply batch to be sent twice. The entire group of messages repeats — not individual message duplication, but the whole reply batch arrives, then arrives again.

This happens regardless of TTS being on or off. With TTS on, you get: text message + text+audio message. With TTS off: two identical text messages. The pattern is consistent — the second batch arrives as a group, right after the first.

Steps to reproduce

  1. Set channels.telegram.streaming.mode to "partial" in openclaw.json
  2. Connect agent to Telegram channel
  3. Send any message that triggers a reply
  4. Observe the entire reply batch delivered twice

Expected behavior

One reply batch per user interaction.

Actual behavior

Reply batch sent twice — the full group of messages repeats. The duplication is per-batch, not per-message.

Workaround

Setting channels.telegram.streaming.mode to "block" eliminates the duplication completely, including with TTS enabled. You still get typing indicators during tool execution and chunked code-block delivery, just no per-token streaming.

"off" also works but kills the typing indicator entirely.

{
  "channels": {
    "telegram": {
      "streaming": {
        "mode": "block"
      }
    }
  }
}

Root cause analysis

The partial streaming mode sends a preview message (edited incrementally as tokens arrive) and then a final delivery. When the final delivery does not properly replace/supersede the preview, both the preview content and the final content appear as separate deliveries — resulting in the entire reply batch appearing twice.

This is likely related to PR #39429 (which addresses TTS-specific duplication via didSendViaTtsTool), but the bug is broader: it affects any reply in partial mode, not just TTS payloads.

OpenClaw version

2026.4.29 (a448042)

Operating system

macOS Darwin 25.3.0 (arm64)

Related issues

  • #30316 (locked — same symptom, broader scope)
  • #39194 (locked — TTS-specific duplicate)
  • PR #39429 (TTS dedup fix, but does not address non-TTS partial streaming duplication)

extent analysis

TL;DR

Setting channels.telegram.streaming.mode to "block" is the most likely fix to prevent reply batches from being sent twice.

Guidance

  • The issue is likely caused by the partial streaming mode not properly replacing the preview message with the final delivery, resulting in duplicate batches.
  • To verify, try setting channels.telegram.streaming.mode to "block" and observe if the duplication is eliminated.
  • As a temporary workaround, setting channels.telegram.streaming.mode to "off" also prevents duplication, but it will disable typing indicators.
  • Reviewing PR #39429 may provide insight into the root cause, as it addresses a similar TTS-specific duplication issue.

Example

{
  "channels": {
    "telegram": {
      "streaming": {
        "mode": "block"
      }
    }
  }
}

Notes

This fix may not address the underlying issue, but it provides a reliable workaround. Further investigation into the partial streaming mode and its interaction with preview and final deliveries is needed to resolve the root cause.

Recommendation

Apply workaround: setting channels.telegram.streaming.mode to "block" is a reliable way to prevent reply batches from being sent twice, as it eliminates the duplication issue.

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

One reply batch per user interaction.

#search optimization#API routing#API middleware#SSR setup#ISR setup

Still need to ship something?

×6

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

Back to top recommendations

TRENDING

openclaw - 💡(How to fix) Fix [Bug]: Telegram partial streaming mode causes duplicate reply batches [1 comments, 1 participants]