Skip to content

fix(telegram): handle channel posts in media handler and thread interim replies - #88903

Open
AdaJyao wants to merge 1 commit into
NousResearch:mainfrom
AdaJyao:fix/telegram-channel-media-reply
Open

fix(telegram): handle channel posts in media handler and thread interim replies#88903
AdaJyao wants to merge 1 commit into
NousResearch:mainfrom
AdaJyao:fix/telegram-channel-media-reply

Conversation

@AdaJyao

@AdaJyao AdaJyao commented Aug 18, 2026

Copy link
Copy Markdown

Summary

Two related Telegram fixes for channel (broadcast) chats, found while using a Hermes bot in a Telegram channel:

1. Forwarded media silently dropped in channels

_handle_media_message checked update.message directly, which is None for channel posts (Telegram delivers those via update.channel_post). Any photo/video/document forwarded into a channel was dropped at the first guard — no log, no event, nothing. The text handler already used _effective_update_message(); the media handler did not.

Fix: resolve msg = self._effective_update_message(update) at the top of _handle_media_message (same as the text/command/location handlers) and use it throughout.

2. Interim replies not threaded to the triggering message in channels

Interim assistant messages (commentary between tool calls) were sent via adapter.send() without reply_to:

  • GatewayStreamConsumer._send_commentary() — the streamed path
  • GatewayRunner._interim_assistant_cb() — the non-streaming fallback path

In a channel (no thread_id), the metadata path also produced no reply anchor, so every interim status message appeared as an unthreaded standalone message. The final reply was threaded correctly (via _reply_anchor_for_event), which made the mid-response messages look inconsistent.

Fix: pass reply_to=self._initial_reply_to_id in _send_commentary() and reply_to=event_message_id in the fallback send() call.

Verification

Live-tested against a real Telegram channel:

  • Forwarded photo into channel → now cached and processed (before: silently dropped, update.message was None)
  • Mid-response commentary messages → now carry reply_to=<triggering message id> (verified via send-path debug logging: reply_to='415' etc.)
  • Final replies → unchanged (already threaded)

Files changed

  • gateway/stream_consumer.py — thread _send_commentary sends
  • gateway/run.py — thread non-streaming interim fallback sends
  • plugins/platforms/telegram/adapter.py — handle channel posts in _handle_media_message

…im replies

Two related Telegram fixes for channel (broadcast) chats:

1. _handle_media_message used update.message directly, which is None for
   channel posts (Telegram delivers those via update.channel_post). Media
   forwarded into a channel was silently dropped before auth checks. Use
   _effective_update_message() like the text handler does.

2. Interim assistant commentary (_send_commentary in the stream consumer,
   and the non-streaming fallback in gateway/run.py) sent without
   reply_to, so mid-response status messages in channels never carried
   the reply anchor to the triggering user message. Thread them via
   initial_reply_to_id / event_message_id.
@alt-glitch alt-glitch added type/bug Something isn't working comp/gateway Gateway runner, session dispatch, delivery comp/plugins Plugin system and bundled plugins platform/telegram Telegram bot adapter P3 Low — cosmetic, nice to have sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages labels Aug 18, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

This was generated by AI during triage.

Related: #51747 already implements the current Telegram adapter channel-media normalization. This PR additionally changes interim reply anchoring, so the overlap is not marked as a duplicate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/gateway Gateway runner, session dispatch, delivery comp/plugins Plugin system and bundled plugins P3 Low — cosmetic, nice to have platform/telegram Telegram bot adapter sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants