hermes - 💡(How to fix) Fix [Bug]: Telegram forum supergroup messages in General topic can fail to reach Hermes at all while DMs still work [1 comments, 1 participants]

Bug Description In a Telegram forum-enabled supergroup, Hermes can appear fully healthy in DMs but stay completely silent in the group even when the bot is explicitly mentioned. In the observed case, messages sent in the supergroup’s General topic never reached normal Hermes processing: no inbound Telegram message was logged by the gateway, no authorization warning was logged, and no response was produced. At the same time, direct messages from the same user continued to arrive and be processed normally.

This looks like a Telegram gateway bug rather than configuration/user error. The bot is running, polling is active, privacy mode is already off, the bot can join groups, the user is authorized, and the group is already known to Hermes. The failure appears to happen before Hermes’s normal Telegram message handling path.

I searched existing issues before filing. Nearby issues include #13195 (Telegram supergroup message_thread_id/session fragmentation), #7519 / #7877 (Telegram forum General topic edge cases), #3634 (missing Telegram update handlers for channel_post), and #3206 (spurious Telegram thread_id handling), but I did not find an exact match for “DM works, forum supergroup General-topic mention produces no inbound log and no reply”.

Steps to Reproduce

1. Run Hermes gateway with Telegram enabled and a working DM setup.
2. Add the bot to a Telegram forum-enabled supergroup (topics enabled).
3. Ensure the bot is a member of the group and the same user can successfully talk to Hermes in DM.
4. In the group’s General topic, send a message such as @HermesAgentAlexBot probe-1 as a normal user.
5. Observe Hermes behavior and check gateway logs.

Observed setup details from the reproduction:

• Group type: Telegram supergroup with is_forum=true
• Chat title: MyHermesGroup
• Chat id: -1003882739081
• Bot username: @HermesAgentAlexBot
• Sender posted as self (not anonymous admin / not sender_chat mode)
• Group is already present in channel_directory.json

Expected Behavior Hermes should receive the Telegram update for the group message, log it as inbound traffic, and either respond normally or at least produce a clear logged reason for ignoring/rejecting it.

Actual Behavior The group message in the forum supergroup General topic produced no visible reply and, more importantly, no normal inbound Telegram log entry in the live gateway logs. DM messages from the same user continued to be received and processed immediately.

Affected Component

• Gateway (Telegram/Discord/Slack/WhatsApp)

Messaging Platform (if gateway-related)

• Telegram

Debug Report Report https://paste.rs/G1jB4 agent.log https://paste.rs/HIK4m gateway.log https://paste.rs/OOS4X

Operating System Ubuntu 24.04 / Linux x86_64

Python Version 3.11.15 (Hermes version output)

Hermes Version Hermes Agent v0.10.0 (2026.4.16)

Additional Logs / Traceback (optional) Relevant live findings from the local investigation:

• getMe returned:
  • can_join_groups: true
  • can_read_all_group_messages: true
• getWebhookInfo returned an empty webhook URL and pending_update_count: 0
• Hermes process was running normally via python -m hermes_cli.main gateway run --replace
• The bot was confirmed as a member of MyHermesGroup
• getChat(-1003882739081) reported:
  • type: supergroup
  • is_forum: true
• The reproducing user is the group creator/admin and is not anonymous in getChatAdministrators
• channel_directory.json already contains the Telegram group entry:
  • -1003882739081 / MyHermesGroup

The key symptom was:

• DM messages from the same user were logged as inbound immediately
• the controlled group probe in General topic was not logged as inbound at all
• there was no Unauthorized user warning for that probe
• there was no normal response path triggered

Root Cause Analysis (optional) Current main source still looks vulnerable to missing/opaque inbound Telegram update handling in this area:

1. In gateway/platforms/telegram.py, the adapter registers handlers for:

• text messages
• commands
• location/venue
• media
• callback queries

But there is no broad diagnostic logging for Telegram updates that are delivered but not routed through one of these normal paths. This makes it hard to distinguish “Telegram never sent the update” from “Telegram sent an update shape Hermes silently ignored”.

1. main still has Telegram forum/general-topic special handling based on message.message_thread_id in _build_message_event(), including:

• thread_id_raw = message.message_thread_id
• fallback to synthetic General topic thread id when chat.is_forum and thread id is absent

Related existing issues show this area has already been fragile:

• #13195: supergroup message_thread_id session fragmentation
• #7519 / #7877: General topic handling edge cases
• #3634: missing explicit handler support for some Telegram update types
• #3206: incorrect/spurious Telegram thread-id propagation

1. The most plausible failure mode from the live investigation is:

• the Telegram update for the General-topic group message is arriving in a shape Hermes does not currently treat as a normal inbound message event, or
• Hermes is silently dropping it before it reaches the standard logging/authorization path.

Proposed Fix (optional) A good next step would be to harden the Telegram adapter with explicit diagnostics before/while fixing the routing bug:

1. Add debug/info logging for ignored/unhandled Telegram updates, including update type and whether message, channel_post, sender_chat, from_user, and message_thread_id are present.
2. Add focused regression coverage for forum supergroup General-topic inbound messages where DMs still work.
3. Verify whether PTB/Telegram is delivering these General-topic messages through a path Hermes currently does not log or handle explicitly.
4. If needed, normalize that update shape into the regular MessageEvent pipeline instead of silently dropping it.

Are you willing to submit a PR for this?

• I’d like to help test a fix, but I am primarily reporting the bug and diagnostic findings for now.