Summary

When an inbound Telegram message contains media (image, voice, etc.), OpenClaw calls the Telegram getFile API to download the attachment. If this network request fails, the entire message is silently dropped — including any text content. There is no retry mechanism and no fallback to deliver the text portion without the attachment.

Steps to reproduce

1. Send a Telegram message with an image attachment + text to an OpenClaw bot
2. If the getFile API call encounters a transient network error, the message is lost
3. The sender sees double-tick (delivered) on Telegram but the bot never processes the message

Expected behavior

• getFile failures should be retried (with backoff) before giving up
• If media download ultimately fails, the text portion of the message should still be delivered to the agent
• At minimum, a warning should be logged that a message was dropped

Actual behavior

• The handler throws HttpError: Network request for 'getFile' failed!
• The message is silently lost — not queued for retry, text not delivered
• Only visible in gateway.err.log:

  08:28:04 [telegram] handler failed: HttpError: Network request for 'getFile' failed!
  08:28:04 Non-fatal unhandled rejection: TypeError: fetch failed
  

• User had to manually re-send the message

Context

This is a recurring issue. On Feb 13, multiple voice messages were lost due to the same getFile failure pattern, requiring a full gateway restart. On Feb 17, an image+text message was lost despite showing as delivered on Telegram.

The Telegram Bot API getFile endpoint is known to have intermittent failures. Other API calls in OpenClaw (Discord, Slack) already have retry logic — Telegram getFile should too.

OpenClaw version

2026.2.15

Operating system

macOS 15 (arm64)

Install method

brew