Related: #24222 (competing fix for background process thread routing). Both address notification routing to wrong Telegram topic, but different approaches — #24222 carries full routing context on completion queue events, while this PR fixes _thread_kwargs_for_send() fallback.

Thanks for the pointer! I looked at #24222 — the two PRs are complementary rather than competing:

• fix(gateway): preserve thread routing for process completions #24222 ensures the full routing context (thread_id, chat_id, etc.) is carried on completion queue events so _build_process_event_source() resolves correctly.
• This PR fixes the downstream issue: even when source.thread_id is correctly resolved, _thread_kwargs_for_send() still returned {} for DM topics without a reply anchor (synthetic events never have a message_id). This caused the Telegram send to drop thread routing entirely.

Both fixes are needed for the full path to work: #24222 ensures the source has the right thread_id, and this PR ensures that thread_id actually gets passed to the Telegram Bot API even without a reply anchor.

I hit the same no-anchor symptom in the resumed final-response path and opened #27937 as a narrow alternative/follow-up.

One important difference: #27937 does not fall back to message_thread_id alone for Hermes-created Telegram DM topic lanes. The current tests and comments treat that as a known partial route that can render outside the visible lane. Instead, it carries direct_messages_topic_id into the base adapter metadata and uses that only when the reply anchor is unavailable.

Hey @Qwinty, thanks for chiming in and for #27937!

Good point about the bare message_thread_id fallback — you're right that without a reply anchor Telegram can render it outside the visible lane in some edge cases. The direct_messages_topic_id approach in your PR is a cleaner long-term solution for that.

This PR was intentionally minimal: fix the immediate symptom (notifications going to the general stream instead of the topic at all) while #24222 and now #27937 address the deeper routing context. Happy to coordinate — if #27937 lands first, this fallback becomes redundant for that path and can be dropped or scoped down.

Let me know if there's anything useful I can do on my end!

Thanks! That makes sense — I’ll keep #27937 focused on the no-reply-anchor DM-topic path and mention that if it lands first, the bare message_thread_id fallback here can be dropped or scoped down. No extra action needed from your side right now; happy to sync if maintainers prefer one combined direction.

Closing in favor of #27212 (same issue #9532, better approach).

The _thread_kwargs_for_send docstring on current main explicitly says:

Hermes-created private-chat topic lanes are marked with telegram_dm_topic_reply_fallback and must send the private topic thread id together with a reply anchor. Live testing showed that either parameter alone can render outside the visible lane.

Your fix falls back to message_thread_id alone — exactly the known-bad route that docstring warns against. #27212 (@fabiosiqueira) captures the triggering message id at process-spawn time and threads it through the synthetic event, supplying a real reply anchor. That respects the docstring invariant.

Also see #27937 (@Qwinty) which solves the resumed-send variant via direct_messages_topic_id fallback — different but complementary mechanism.

Thanks for the diagnosis on #9532; #27212 takes it to a working fix.