Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix [Telegram] MEDIA: tag in assistant reply sends image twice [3 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#68862•Fetched 2026-04-19 15:06:47
View on GitHub
Comments
2
Participants
2
Timeline
11
Reactions
0
Author
DavidKrispinDavidKrispin
Participants
DavidKrispinDavidKrispinSanjays2402Sanjays2402
Timeline (top)
referenced ×4cross-referenced ×3commented ×2mentioned ×1

When the assistant includes a MEDIA:/path/to/image.png tag in its reply text, Telegram receives the image twice.

Root Cause

Root cause analysis (from source)

Fix Action

Fixed

PR fix notes

PR #68873: fix(auto-reply): dedupe block replies on normalized media paths (fixes #68862)

Description (problem / solution / changelog)

Fixes #68862.

Problem

When a reply includes a MEDIA: tag pointing to a file outside ~/.openclaw/media/outbound/ (e.g. /tmp/foo.png or a workspace path), Telegram (and likely every channel that honours the tag) sends the image twice:

  1. Once via the block-streaming / direct-send path as the reply is flushed.
  2. Once more by the end-of-run final flush in buildReplyPayloads, because its dedup check silently misses.

Both sending paths store their "already sent" keys against the post-normalization payload (whose mediaUrl has been resolved to the outbound location). The final-payload filter in buildReplyPayloads, however, computed its dedup key against the original pre-normalization payload. Different paths → different keys → no match → duplicate delivery.

Payloads whose MEDIA: already pointed inside the outbound directory (so normalization was a no-op) happened to dedupe correctly, which explains why the bug has gone unnoticed for inline-generated media but bites for user-attached workspace/tmp paths.

Fix

In buildReplyPayloads, when we're about to consult blockReplyPipeline.hasSentPayload or directlySentBlockKeys, run each candidate through normalizeReplyPayloadMedia first and do the lookup on the normalized payload. That is the exact same transform the sending paths ran before stashing their keys, so the keys line up.

  • Payloads with no media are unaffected — normalizeReplyPayloadMedia is a no-op when there's nothing to normalize.
  • Pre-existing branches (shouldDropFinalPayloads, "no pipeline and no direct-send set") are untouched, so there's no extra async work on hot paths that don't need the dedup check.
  • The existing async normalizeMediaPaths helper is already plumbed through buildReplyPayloadsParams, so nothing new to wire.

Tests

Two new cases in agent-runner-payloads.test.ts, one per affected path, both asserting the payload is dropped:

  • deduplicates direct-send block keys using normalized media paths (regression: #68862) — stores a block key against the outbound path, then feeds a payload whose mediaUrl is the pre-normalization workspace path.
  • deduplicates pipeline-sent payloads using normalized media paths (regression: #68862) — same shape, but via a blockReplyPipeline stub whose hasSentPayload only matches the outbound path.

Both fail on main and pass with this change.

Verification

  • pnpm exec vitest run src/auto-reply/reply/agent-runner-payloads.test.ts — 17 pass (2 new).
  • pnpm exec vitest run src/auto-reply/reply/reply-delivery.test.ts src/auto-reply/reply/block-reply-pipeline.test.ts — 14 pass, no regressions in adjacent suites.
  • pnpm tsgo:all — clean across core, core:test, extensions, extensions:test.
  • pnpm exec oxlint on the two touched files — 0 warnings, 0 errors.

Commit was made with --no-verify because the repo's pre-commit pnpm lint trips on a pre-existing, unrelated typescript-eslint(no-duplicate-type-constituents) error in ui/src/ui/controllers/cron.ts:614 (existingChannel?: string | undefined). Happy to file a follow-up PR for that if useful.

Out of scope

  • The underlying design smell — two subsystems storing "sent" keys with two different shapes of the same payload — isn't addressed here. A future cleanup could hoist normalization earlier so every key is computed from the same canonical form. This PR is the minimum-viable fix.

Changed files

  • src/auto-reply/reply/agent-runner-payloads.test.ts (modified, +74/-0)
  • src/auto-reply/reply/agent-runner-payloads.ts (modified, +32/-11)

PR #68968: fix(telegram): dedup MEDIA using normalized payload path

Description (problem / solution / changelog)

Summary

Use params.payload for the dedup key instead of params.trackingPayload to match what final payload delivery computes.

Closes #68862

Changed files

PR #68971: fix(telegram): dedup MEDIA using normalized path

Description (problem / solution / changelog)

Use params.payload instead of params.trackingPayload for the dedup key.

Closes #68862

Changed files

RAW_BUFFERClick to expand / collapse

Description

When the assistant includes a MEDIA:/path/to/image.png tag in its reply text, Telegram receives the image twice.

Root cause analysis (from source)

The issue is in the block streaming deduplication path. When block streaming is enabled:

  1. createBlockReplyDeliveryHandler (in src/auto-reply/reply/reply-delivery.ts) processes the streamed payload:

    • Calls normalizeReplyPayloadDirectives → parses MEDIA: tag → extracts mediaUrl
    • Calls normalizeMediaPaths → resolves/persists the file to a new outbound path (e.g. ~/.openclaw/media/outbound/xxx.png)
    • Sends the media via sendMedia
    • Stores createBlockReplyContentKey(blockPayload) in directlySentBlockKeys — with the normalized (new) path

  2. Final payload delivery (in src/auto-reply/reply/agent-runner-payloads.ts) processes the same content:

    • createBlockReplyContentKey(payload) is computed before normalizeMediaPaths runs → uses the original path (e.g. /home/user/workspace/image.png)
    • Since the keys do not match (original path ≠ normalized outbound path), the dedup check passes
    • The image is sent a second time

Expected behavior

Image sent once.

Actual behavior

Image sent twice — once during block streaming, once in final payload delivery.

Suggested fix

Either:

  • Compute the content key for dedup after normalizeMediaPaths in both paths
  • Or normalize media paths before the dedup check in agent-runner-payloads.ts

Environment

  • OpenClaw 2026.4.15
  • Channel: Telegram
  • Block streaming: enabled

Reproduction

Have the assistant reply with only MEDIA:/path/to/local/image.png — the image arrives twice in Telegram.

extent analysis

TL;DR

Compute the content key for deduplication after normalizing media paths to ensure consistent keys and prevent duplicate image sends.

Guidance

  • Review the createBlockReplyDeliveryHandler function in src/auto-reply/reply/reply-delivery.ts to understand how media paths are normalized and content keys are generated.
  • In src/auto-reply/reply/agent-runner-payloads.ts, consider normalizing media paths before computing the content key for deduplication to ensure consistency with the block streaming path.
  • Verify that the normalizeMediaPaths function correctly resolves and persists media files to their new outbound paths.
  • Test the fix by having the assistant reply with a MEDIA: tag and checking if the image is sent only once to Telegram.

Example

No code snippet is provided as the issue is more related to the logic and timing of media path normalization and content key generation.

Notes

The fix assumes that normalizing media paths before computing the content key will resolve the deduplication issue. However, additional testing and verification are necessary to ensure the fix works as expected in all scenarios.

Recommendation

Apply the suggested fix by computing the content key for deduplication after normalizing media paths, as this approach ensures consistency between the block streaming and final payload delivery paths.

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

Image sent once.

#container setup#orchestration issue#cache issue#memory leak#API versioning

Still need to ship something?

×6

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

Back to top recommendations

TRENDING