fix(telegram): route outbound media downloads through proxy transport by hhhhao28 · Pull Request #47387 · openclaw/openclaw

hhhhao28 · 2026-03-15T14:19:05Z

Summary

Problem: Telegram remote media sends/replies still downloaded media via the generic outbound media loader, which did not receive Telegram's proxy-aware transport.
Why it matters: In proxy-required environments, Telegram media sends could fail before sendPhoto/sendDocument because the prefetch path bypassed the configured proxy.
What changed: threaded Telegram transport options through outbound media loading so remote media prefetch uses the same proxy fetch + dispatcher/fallback policies as Telegram API traffic; added regression tests for send and reply paths.
What did NOT change (scope boundary): did not change Telegram inbound media handling semantics, message formatting behavior, or non-Telegram channel transports.

Change Type (select all)

Bug fix

Scope (select all touched areas)

Integrations

Linked Issue/PR

Closes [Bug]: Telegram media download uses native fetch instead of proxy-aware fetch #46282

User-visible / Behavior Changes

Telegram remote media sends/replies now honor configured Telegram proxy transport during outbound media prefetch.

Security Impact (required)

New permissions/capabilities? (No)
Secrets/tokens handling changed? (No)
New/changed network calls? (No)
Command/tool execution surface changed? (No)
Data access scope changed? (No)

Repro + Verification

Steps

Configure Telegram with a proxy-required environment.
Send or reply with a remote media URL through Telegram.
Confirm the outbound media prefetch succeeds and the media is delivered.

Expected

Remote Telegram media delivery succeeds through the configured proxy transport.

Actual

Previously, outbound media prefetch could bypass the proxy-aware transport and fail before delivery.

Evidence

Failing path covered by regression tests

Human Verification (required)

Verified scenarios: targeted unit tests for outbound Telegram send path, Telegram reply delivery path, and outbound media load option plumbing.
Edge cases checked: cached transport reuse, fallback policy propagation, local media roots still passed through unchanged.
What you did not verify: live Telegram delivery against a real proxy server.

Compatibility / Migration

Backward compatible? (Yes)
Config/env changes? (No)
Migration needed? (No)

Failure Recovery (if this breaks)

How to disable/revert this change quickly: revert commit 6f864e21f.
Files/config to restore: Telegram outbound media loading path and shared media loader option plumbing.
Known bad symptoms reviewers should watch for: remote media URLs loading without proxy transport, or non-Telegram outbound media loaders receiving unexpected option handling.

Risks and Mitigations

Risk: shared outbound media loader now accepts more transport options.
Mitigation: behavior remains opt-in; existing callers are unchanged unless they pass the new fields.

greptile-apps · 2026-03-15T14:22:07Z

Greptile Summary

This PR fixes a proxy bypass bug by threading Telegram's configured transport options (sourceFetch, dispatcherPolicy, fallbackDispatcherPolicy, shouldRetryFetchError) through the outbound media prefetch path (loadWebMedia / fetchRemoteMedia), so media downloads before sendPhoto/sendDocument honor the same proxy and IPv4-fallback policies as Telegram API traffic.

Key changes:

src/media/load-options.ts: Introduces OutboundMediaFetchOptions and composes it into OutboundMediaLoadParams / OutboundMediaLoadOptions via intersection types; buildOutboundMediaLoadOptions forwards all four new fields.
extensions/whatsapp/src/media.ts: Exposes the new transport options through WebMediaOptions, loadWebMedia, and loadWebMediaRaw, passing them down to fetchRemoteMedia.
extensions/telegram/src/send.ts: Extracts a new telegramTransportCache, resolves the transport once per API context (resolveTelegramTransportForAccount), and passes sourceFetch + policies to buildOutboundMediaLoadOptions.
extensions/telegram/src/bot/delivery.replies.ts: Adds telegramTransport to deliverMediaReply and propagates it via buildOutboundMediaLoadOptions.
Remaining files (bot-message-dispatch.ts, bot-message.ts, bot-native-commands.ts, bot.ts): Minimal threading of telegramTransport through each call layer.
Regression tests added for both the sendMessageTelegram and deliverReplies paths.

No issues found. The change is well-scoped, backward-compatible, and the retry guard in fetchRemoteMedia (fallbackDispatcherPolicy && shouldRetryFetchError(err)) ensures unconditional shouldRetryFetchError assignment in send.ts is safe even when no fallback policy is present.

Confidence Score: 5/5

This PR is safe to merge; the change is backward-compatible and well-tested.
All new fields are optional and existing callers are unaffected. Transport caching mirrors the well-established telegramClientOptionsCache pattern with identical eviction logic. The shouldRetryFetchError is always set in send.ts but is harmless when fallbackDispatcherPolicy is absent, as fetchRemoteMedia guards on both. Regression tests cover both the send and reply delivery paths. No logic errors, security concerns, or breaking changes detected.
No files require special attention.

_{Last reviewed commit: 6f864e2}

clawsweeper · 2026-04-28T07:08:03Z

Thanks for the context here. I swept through the related work, and this is now duplicate or superseded.

Keep open; the bug-fix direction is valid, but this branch is conflicting and stale against current main's media transport contract, and it still lacks required real Telegram/proxy proof.

Canonical path: Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review.

So I’m closing this here because the remaining work is already tracked in the canonical issue.

Review details

Best possible solution:

Close this stale PR. The latest review rated it F, the branch still lacks merge-ready proof, and there has been no human follow-up after the durable review.

Do we have a high-confidence way to reproduce the issue?

Yes, by source inspection: current main's direct-send and final-reply remote media paths call loadWebMedia without Telegram transport fields. A live repro would configure Telegram in a proxy-required environment and send or reply with a remote media URL.

Is this the best way to solve the issue?

No, not as currently proposed. The direction is right, but the branch must be rebased to current main's dispatcherAttempts, shouldRetryTelegramTransportFallback, and trustExplicitProxyDns media contract before it is the narrow maintainable fix.

Security review:

Security review needs attention: The patch touches guarded remote media fetching and must be ported without losing current SSRF and explicit-proxy DNS protections.

[medium] Preserve guarded fetch transport semantics — extensions/telegram/src/send.ts:811
The PR uses older dispatcher policy plumbing for remote media fetches; current main's security boundary uses dispatcherAttempts with trustExplicitProxyDns, so a rebase must preserve hostname policy checks and trusted explicit-proxy handling.
Confidence: 0.84

What I checked:

stale F-rated PR: PR was opened 2026-03-15T14:19:05Z, is older than 60 days, and the latest review rated it F.
proof blocker: real behavior proof is missing and proof tier is F, so this branch is not merge-ready without contributor follow-up.
no human follow-up: live comments and timeline hydrated by apply contain no non-automation activity after the ClawSweeper review.

Likely related people:

vincentkoc: Authored the trusted explicit-proxy media DNS fix and the delivery media-loader seam that define the current proxy/media behavior this PR must preserve. (role: adjacent proxy/media contributor; confidence: high; commits: e58d50b7a848, 79d7fdce932b; files: src/media/fetch.ts, extensions/telegram/src/bot/delivery.replies.ts)
obviyus: Authored the dispatcherAttempts-based Telegram transport fallback chain that this branch needs to port to before merge. (role: transport contract contributor; confidence: high; commits: e4825a0f9385; files: extensions/telegram/src/fetch.ts, src/media/fetch.ts)
jalehman: Recently worked on Telegram native command delivery, one of the reply paths that must continue to receive correct media prefetch options after rebasing. (role: adjacent native-command contributor; confidence: medium; commits: ed8d5b379791; files: extensions/telegram/src/bot-native-commands.ts)
RomneyDa: Current-main blame places the reviewed Telegram/media files under a recent broad main update, so this person is relevant for current-file provenance but less likely to own the original behavior. (role: recent area contributor; confidence: low; commits: d391434f4e45; files: extensions/telegram/src/send.ts, extensions/telegram/src/bot/delivery.replies.ts, extensions/telegram/src/fetch.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against 6981051682f2.

clawsweeper · 2026-05-20T17:44:44Z

ClawSweeper PR egg

🎁 Pass real behavior proof to wake the egg and unlock a hatchable treat.

Where did the egg go?

The egg game starts only after the PR passes the real-behavior proof check.
Before that, no creature or rarity is rolled. The treat waits for real proof.
This is still just collectible flavor: proof affects review readiness, not creature quality.

clawsweeper · 2026-05-24T05:44:29Z

ClawSweeper applied the proposed close for this PR.

Action: closed this PR.
Close reason: duplicate or superseded.
Evidence: durable ClawSweeper review.

fix(telegram): route outbound media downloads through proxy transport

6f864e2

openclaw-barnacle Bot added channel: telegram Channel integration: telegram channel: whatsapp-web Channel integration: whatsapp-web size: M labels Mar 15, 2026

Fix CI for telegram proxy PR

f2e34b7

clawsweeper Bot added the mantis: telegram-visible-proof Mantis should capture Telegram visible proof. label May 11, 2026

openclaw-barnacle Bot added the triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. label May 11, 2026

clawsweeper Bot mentioned this pull request May 15, 2026

[Bug]: Telegram final replies with media ignore configured mediaMaxMb in outbound delivery path #46023

Closed

clawsweeper Bot mentioned this pull request May 20, 2026

fix(telegram): honor outbound media max bytes #83478

Merged

clawsweeper Bot closed this May 24, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix(telegram): route outbound media downloads through proxy transport#47387

fix(telegram): route outbound media downloads through proxy transport#47387
hhhhao28 wants to merge 2 commits into
openclaw:mainfrom
hhhhao28:codex/issue-46282-telegram-media-proxy

hhhhao28 commented Mar 15, 2026

Uh oh!

greptile-apps Bot commented Mar 15, 2026

Uh oh!

clawsweeper Bot commented Apr 28, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 20, 2026

Uh oh!

clawsweeper Bot commented May 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Uh oh!

Uh oh!

Conversation

hhhhao28 commented Mar 15, 2026

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Steps

Expected

Actual

Evidence

Human Verification (required)

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Uh oh!

greptile-apps Bot commented Mar 15, 2026

Greptile Summary

Confidence Score: 5/5

Uh oh!

clawsweeper Bot commented Apr 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

clawsweeper Bot commented May 20, 2026

Uh oh!

clawsweeper Bot commented May 24, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

clawsweeper Bot commented Apr 28, 2026 •

edited

Loading