Bug Description
Cron jobs and send_message tool calls fail to deliver messages to Telegram on networks where api.telegram.org is blocked (e.g., Russia), while the gateway's live Telegram adapter works fine.
Root Cause
The gateway's Telegram adapter (gateway/platforms/telegram.py) creates its Bot with a custom HTTPXRequest that uses TelegramFallbackTransport — this transport resolves api.telegram.org via DNS-over-HTTPS (Google/Cloudflare DoH) and falls back to hardcoded IPs like 149.154.167.220 when the system DNS returns a blocked IP.
However, tools/send_message_tool.py → _send_telegram() (line ~700) creates Bot(token=token) with the default HTTPXRequest, bypassing all fallback logic:
# gateway/platforms/telegram.py — WORKS
from telegram.request import HTTPXRequest
# ... TelegramFallbackTransport injected into HTTPXRequest
# tools/send_message_tool.py — FAILS
from telegram import Bot
bot = Bot(token=token) # default transport, no fallback
Impact
- Cron jobs with
deliver: "telegram:CHAT_ID" timeout on api.telegram.org:443
send_message tool calls from agents also fail on blocked networks
- Users see
curl: (28) Connection timed out or httpx.ConnectTimeout in logs
- Gateway continues to work because it uses the fallback transport
Expected Behavior
send_message_tool._send_telegram should use the same TelegramFallbackTransport as the gateway adapter, ensuring consistent delivery regardless of network conditions.
Steps to Reproduce
- Run Hermes on a network where
api.telegram.org is blocked
- Create a cron job with
deliver: "telegram:CHAT_ID"
- Job executes but delivery fails with connection timeout
- Meanwhile, gateway-originated messages work fine
Suggested Fix
Make _send_telegram create Bot with the same custom HTTPXRequest that the gateway uses, or refactor to share a single create_telegram_bot() helper between gateway and send_message_tool.
Environment
- Hermes Agent: latest main (May 2026)
- Platform: Telegram
- Network:
api.telegram.org blocked at DNS level
Related Code
gateway/platforms/telegram_network.py — TelegramFallbackTransport, discover_fallback_ips()
gateway/platforms/telegram.py — gateway adapter with custom HTTPXRequest
tools/send_message_tool.py — _send_telegram() line ~700
cron/scheduler.py — _deliver_output() calls _send_to_platform → _send_telegram
Bug Description
Cron jobs and
send_messagetool calls fail to deliver messages to Telegram on networks whereapi.telegram.orgis blocked (e.g., Russia), while the gateway's live Telegram adapter works fine.Root Cause
The gateway's Telegram adapter (
gateway/platforms/telegram.py) creates itsBotwith a customHTTPXRequestthat usesTelegramFallbackTransport— this transport resolvesapi.telegram.orgvia DNS-over-HTTPS (Google/Cloudflare DoH) and falls back to hardcoded IPs like149.154.167.220when the system DNS returns a blocked IP.However,
tools/send_message_tool.py→_send_telegram()(line ~700) createsBot(token=token)with the defaultHTTPXRequest, bypassing all fallback logic:Impact
deliver: "telegram:CHAT_ID"timeout onapi.telegram.org:443send_messagetool calls from agents also fail on blocked networkscurl: (28) Connection timed outorhttpx.ConnectTimeoutin logsExpected Behavior
send_message_tool._send_telegramshould use the sameTelegramFallbackTransportas the gateway adapter, ensuring consistent delivery regardless of network conditions.Steps to Reproduce
api.telegram.orgis blockeddeliver: "telegram:CHAT_ID"Suggested Fix
Make
_send_telegramcreateBotwith the same customHTTPXRequestthat the gateway uses, or refactor to share a singlecreate_telegram_bot()helper between gateway andsend_message_tool.Environment
api.telegram.orgblocked at DNS levelRelated Code
gateway/platforms/telegram_network.py—TelegramFallbackTransport,discover_fallback_ips()gateway/platforms/telegram.py— gateway adapter with customHTTPXRequesttools/send_message_tool.py—_send_telegram()line ~700cron/scheduler.py—_deliver_output()calls_send_to_platform→_send_telegram