Skip to content

fix: new Telegram DM topics from All Messages reroute to previous session#29546

Closed
viraniaman94 wants to merge 1 commit into
NousResearch:mainfrom
viraniaman94:fix/telegram-dm-topic-new-lane-routing
Closed

fix: new Telegram DM topics from All Messages reroute to previous session#29546
viraniaman94 wants to merge 1 commit into
NousResearch:mainfrom
viraniaman94:fix/telegram-dm-topic-new-lane-routing

Conversation

@viraniaman94

Copy link
Copy Markdown

Summary

When topic mode is enabled and a user creates a new topic from Telegram's "All Messages" view, the first message in that topic often arrives without is_topic_message=True. This caused _build_message_event to strip the message_thread_id, and _recover_telegram_topic_thread_id redirected the resulting lobby thread_id to the user's most recent binding — making the brand-new topic inherit the previous topic's session.

Changes

1. gateway/platforms/telegram.py_build_message_event

When is_topic_message is False for a DM that has a message_thread_id:

  • Check if topic mode is enabled
  • Check if the thread_id is not yet bound to any session (genuinely new topic)
  • If both true, preserve the thread_id so the topic gets its own session lane
  • If the thread_id IS already known (cross-topic Reply leak), strip it and let the recovery function handle routing

2. gateway/run.py_recover_telegram_topic_thread_id

Only recover from the lobby/General topic (thread_id=None / "" / "1") where routing intent is truly ambiguous. Non-lobby unknown thread_ids are treated as genuinely new topic lanes and left alone.

3. tests/gateway/test_telegram_topic_mode.py — updated tests

  • Replaced test_recover_rewrites_unknown_thread_id_to_most_recent with test_recover_leaves_unknown_topic_alone (the old test codified the buggy behavior)
  • Added test_recover_redirects_cross_topic_reply_to_known_topic (known topic stays put)
  • Added test_recover_rewrites_cross_topic_reply_to_unknown_topic (unknown non-lobby returns None)

Testing

  • All 44 tests in test_telegram_topic_mode.py pass
  • Verified working in production: creating a new topic from All Messages now correctly gets its own Hermes session

…ession

When topic mode is enabled and a user creates a new topic from Telegram's
'All Messages' view, the first message in that topic often arrives without
is_topic_message=True. _build_message_event stripped the message_thread_id,
and _recover_telegram_topic_thread_id redirected the resulting lobby
thread_id (None) to the user's most recent binding — causing the brand-new
topic to inherit the previous topic's session.

Two-part fix:

1. gateway/telegram.py (_build_message_event): When is_topic_message is
   False for a DM with message_thread_id, check if topic mode is enabled
   and the thread_id is not yet bound to any session. If genuinely new,
   preserve the thread_id so the topic gets its own session lane.

2. gateway/run.py (_recover_telegram_topic_thread_id): Only recover from
   the lobby/General topic (thread_id=None/'') where routing intent is
   ambiguous. Non-lobby unknown thread_ids are treated as genuinely new
   lanes and left alone.
@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists comp/gateway Gateway runner, session dispatch, delivery platform/telegram Telegram bot adapter duplicate This issue or pull request already exists labels May 21, 2026
@alt-glitch

Copy link
Copy Markdown
Collaborator

Duplicate of #28605. This fixes the same _recover_telegram_topic_thread_id regression (#26609) where brand-new DM topics are hijacked into the previous session — identical root cause and fix approach as #29287 (already marked dup of #28605).

@teknium1

Copy link
Copy Markdown
Contributor

Superseded by #31444 (#31444), which fixes the same #31086 hijack with a smaller, single-site change in _recover_telegram_topic_thread_id rather than also modifying _build_message_event. The recovery function's lobby/General path already handles the cases the _build_message_event change was targeting, so the broader two-part fix wasn't needed. Thanks for digging into the strip-on-non-topic-message angle though — it helped frame the comparison. Closes #31086.

@teknium1 teknium1 closed this May 24, 2026
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 duplicate This issue or pull request already exists P2 Medium — degraded but workaround exists platform/telegram Telegram bot adapter type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants