Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Bug]: Telegram first assistant reply can deliver text but drop attachment when reply contains text + MEDIA: [1 pull requests, 2 comments, 2 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#75156•Fetched 2026-05-01 05:37:32
View on GitHub
Comments
2
Participants
2
Timeline
11
Reactions
2
Author
cslash-zzcslash-zz
Participants
clawsweeper[bot]clawsweeper[bot]cslash-zzcslash-zz
Timeline (top)
referenced ×8commented ×2cross-referenced ×1

When an assistant reply contains both visible text and a MEDIA: attachment, Telegram can receive the text but not the attachment on the first send. If the same file is requested again, the attachment may arrive on the retry, often without the original accompanying text.

Root Cause

Root cause hypothesis

The Telegram delivery layer itself appears capable of sending text + media correctly.

Fix Action

Fixed

PR fix notes

PR #75180: fix(reply): delivery-aware media tracking in block reply pipeline (#75156)

Description (problem / solution / changelog)

Summary

When an assistant reply contains both visible text and a MEDIA attachment, the block reply pipeline prematurely marks the media URL as already sent during streaming. The final reply dedupe pass then strips the attachment, leaving only text.

Closes #75156

Root Cause

In block-reply-pipeline.ts, sendPayload() unconditionally adds ALL media URLs to sentMediaUrls after a block send. Downstream, filterMessagingToolMediaDuplicates() in agent-runner-payloads.ts sees those URLs in sentMediaUrls and strips them from the final reply.

Fix: Delivery-Aware Media Tracking

Make the onBlockReply callback optionally return {sentMediaUrls} to confirm which media URLs were actually delivered by the channel handler. The pipeline only tracks confirmed URLs for dedupe.

When the callback returns void (legacy callers), fall back to media-only tracking for backwards compatibility.

Changes (5 files)

  1. block-reply-pipeline.ts: Add BlockReplyResult type. Update onBlockReply signature to accept BlockReplyResult return. Track only callback-confirmed media URLs, with media-only fallback for void callbacks.
  2. get-reply-options.types.ts: Update public onBlockReply type to accept BlockReplyResult.
  3. dispatch-from-config.ts: Production callback returns confirmed media URLs from normalizedPayload.
  4. block-reply-pipeline.test.ts: Add tests for delivery-confirmed tracking, empty confirmation, and legacy void fallback.
  5. CHANGELOG.md: User-facing fix entry.

Testing

All 177 related tests pass:

  • block-reply-pipeline.test.ts (16 tests)
  • agent-runner-payloads.test.ts (27 tests)
  • Telegram lane-delivery.test.ts (27 tests)
  • Telegram bot-message-dispatch.test.ts (107 tests)

Risk

Low. The onBlockReply signature change is backwards-compatible (void return is still accepted). The fallback path preserves the previous media-only tracking behavior for legacy callbacks.

Changed files

  • CHANGELOG.md (modified, +1/-0)
  • src/auto-reply/get-reply-options.types.ts (modified, +9/-1)
  • src/auto-reply/reply/block-reply-pipeline.test.ts (modified, +40/-1)
  • src/auto-reply/reply/block-reply-pipeline.ts (modified, +24/-7)
  • src/auto-reply/reply/dispatch-from-config.ts (modified, +6/-1)
  • src/auto-reply/reply/reply-delivery.ts (modified, +9/-3)
RAW_BUFFERClick to expand / collapse

[Bug]: Telegram first assistant reply can deliver text but drop attachment when reply contains text + MEDIA:

Version

  • OpenClaw 2026.4.25

Affected surface

  • Telegram direct chat

Summary

When an assistant reply contains both visible text and a MEDIA: attachment, Telegram can receive the text but not the attachment on the first send. If the same file is requested again, the attachment may arrive on the retry, often without the original accompanying text.

Expected behavior

A single assistant reply containing text plus MEDIA: should deliver both:

  • the text/caption/message body
  • the attachment

Actual behavior

On the first send:

  • text is delivered
  • attachment is missing

On a retry of the same file:

  • attachment is delivered
  • often without the original accompanying text

Reproduction

  1. In a Telegram direct chat, ask the assistant to send a normal visible reply with a local file or image attached via MEDIA: in the same reply.
  2. Observe the first delivery.
  3. Ask the assistant to send the same file again.

Observed result before fix

  • First reply: text arrived, attachment did not.
  • Retry: attachment arrived separately.

Root cause hypothesis

The Telegram delivery layer itself appears capable of sending text + media correctly.

The issue appears earlier in outbound reply finalization:

  1. MEDIA: is parsed into reply payload media correctly.
  2. Block/stream reply machinery records media URLs as already sent.
  3. Final reply payload later passes through media dedupe.
  4. The final payload loses its media while keeping text.

That matches the symptom exactly: first reply keeps text but drops the file.

Suspected code path

  • dist/parse-BI9RumYE.js
  • dist/payloads-9eOIDlMA.js
  • dist/block-reply-pipeline-B-BbstCE.js
  • dist/agent-runner.runtime-BBZ7HfEt.js
  • dist/extensions/telegram/delivery-BBABDCGB.js

Minimal fix that resolved it locally

In dist/block-reply-pipeline-B-BbstCE.js, media URLs were being added to sentMediaUrls too aggressively during block reply handling.

Local fix:

  • only treat block-streamed media as dedupe-safe when the streamed block payload is media-only
  • do not mark mixed text+media block payload media as already sent at that stage

Validation

After applying that change locally and restarting the gateway:

  • the first Telegram reply delivered both text and attachment together
  • the original bug no longer reproduced in the live test

Why this seems safe

This preserves duplicate suppression for truly media-only streamed payloads while avoiding premature stripping of attachments from mixed text+media final replies.

Optional follow-up

It may be worth adding a regression test for:

  • first reply with text + MEDIA:
  • block streaming enabled
  • Telegram delivery
  • final payload dedupe still active

extent analysis

TL;DR

Modify the dist/block-reply-pipeline-B-BbstCE.js file to only mark media URLs as sent when the block payload is media-only, to prevent dropping attachments in mixed text+media replies.

Guidance

  • Review the dist/block-reply-pipeline-B-BbstCE.js file to ensure media URLs are not being added to sentMediaUrls too aggressively.
  • Update the code to only treat block-streamed media as dedupe-safe when the streamed block payload is media-only.
  • Verify the fix by testing the first Telegram reply with both text and a MEDIA: attachment to ensure both are delivered together.
  • Consider adding a regression test for this specific scenario to prevent future regressions.

Example

// In dist/block-reply-pipeline-B-BbstCE.js
if (isMediaOnlyBlockPayload) {
  // Mark media URLs as sent for dedupe
  sentMediaUrls.add(mediaUrl);
} else {
  // Do not mark media URLs as sent for mixed text+media payloads
  // ...
}

Notes

This fix assumes that the issue is indeed caused by the aggressive marking of media URLs as sent during block reply handling. Further testing and validation may be necessary to ensure this fix does not introduce other issues.

Recommendation

Apply the workaround by modifying the dist/block-reply-pipeline-B-BbstCE.js file as described, to prevent dropping attachments in mixed text+media replies. This fix seems safe as it preserves duplicate suppression for media-only payloads while avoiding premature stripping of attachments from mixed text+media final replies.

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

A single assistant reply containing text plus MEDIA: should deliver both:

  • the text/caption/message body
  • the attachment
#SSR setup#ISR setup#authentication setup#request error#file not found

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 - ✅(Solved) Fix [Bug]: Telegram first assistant reply can deliver text but drop attachment when reply contains text + MEDIA: [1 pull requests, 2 comments, 2 participants]