openclaw - 💡(How to fix) Fix bug(telegram): Compressed photo delivery still needs deterministic handling [1 participants]

Context

This is a follow-up to stale-closed issue #15078, which is now locked and cannot be commented on or revived in place.

Why this needs a fresh issue

The previous issue was auto-closed for inactivity, but the issue history does not show a clear fix reference or closing PR. Because the old issue is locked, the only way to get this reconsidered is a new report.

The product-level bug

Telegram users naturally send images as compressed photos, not as documents. When compressed photo handling is intermittent or fails silently, users experience:

• image appears sent on Telegram side
• no usable image event reaches the agent/session
• no deterministic user-facing error or fallback
• the bot just seems flaky

Even when “send as file/document instead” works as a workaround, that is not a full fix.

Why this is still high impact

This is a core multimodal path on a major channel. Silent media drops are worse than explicit failure because the user cannot tell whether:

• the image was received
• the agent is processing it
• the channel plugin dropped it
• the model failed later

What would count as a real fix

At minimum, one of these should be true:

1. compressed photos are handled reliably end-to-end, or
2. failures are surfaced deterministically with logging + user-visible fallback instead of silent drops

Suspected areas worth rechecking

• Telegram photo vs document handling path
• largest PhotoSize selection
• media download retries / backoff
• race conditions around Telegram compressed photo availability
• explicit fallback/error emission when download or attachment processing fails

Request

Please reconsider/re-triage this, or point to the exact release/PR that fixed compressed-photo delivery if it already exists.

Prior issue

• Stale-closed predecessor: #15078