You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
add direct_messages_topic_id to the base platform thread metadata for Telegram DM topics, matching the GatewayRunner metadata path
when a DM-topic reply fallback has no reply anchor, send with direct_messages_topic_id instead of dropping all topic kwargs
add regression coverage for resumed/synthetic DM-topic sends without reply anchors
Root cause
After a gateway shutdown/resume, the final response path goes through gateway/platforms/base.py::_thread_metadata_for_source. That helper marked Telegram private topics with telegram_dm_topic_reply_fallback, but it did not include direct_messages_topic_id. Resumed/synthetic events often have no message_id, so TelegramAdapter._thread_kwargs_for_send() returned {} for the no-anchor fallback path and delivered the response to the root DM / All Messages lane even though the session key still had the topic thread_id.
GatewayRunner._thread_metadata_for_source already had the direct-topic metadata path from the earlier synthetic/queued-message fix, but the base adapter helper and adapter no-anchor fallback were missing the same routing.
This intentionally does not fall back to message_thread_id alone for the no-anchor case; live Telegram DM-topic replies still keep the reply-anchor route, while synthetic/resumed sends use direct_messages_topic_id when metadata has it.
BoardJames triage: this looks shared/systemic rather than branch-local. The PR-specific checks (lint/nix/e2e/builds/attribution/history) are green where completed; the remaining blocker is the main Tests / test job, which is currently failing/timing out across unrelated PRs and on main itself (latest main run hit the same aux/session_search + kanban dashboard + compression/Anthropic test drift). I pushed the missing aux/session_search default fix onto the existing systemic fix PR #27931 and validated the affected files locally (125 passed). Next action is maintainer review/workflow approval/merge of #27931, then rerun this PR's Tests / test; no branch-local author action is indicated from the logs I can see.
Merged — cherry-picked your commit onto current main with authorship preserved (rebase-merge). 35/35 thread-fallback tests passing. Docstring conflict resolved against the just-merged #24004 (reply_to_mode). Thanks.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
comp/gatewayGateway runner, session dispatch, deliveryP2Medium — degraded but workaround existsplatform/telegramTelegram bot adaptertype/bugSomething isn't working
4 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
direct_messages_topic_idto the base platform thread metadata for Telegram DM topics, matching the GatewayRunner metadata pathdirect_messages_topic_idinstead of dropping all topic kwargsRoot cause
After a gateway shutdown/resume, the final response path goes through
gateway/platforms/base.py::_thread_metadata_for_source. That helper marked Telegram private topics withtelegram_dm_topic_reply_fallback, but it did not includedirect_messages_topic_id. Resumed/synthetic events often have nomessage_id, soTelegramAdapter._thread_kwargs_for_send()returned{}for the no-anchor fallback path and delivered the response to the root DM / All Messages lane even though the session key still had the topicthread_id.GatewayRunner._thread_metadata_for_sourcealready had the direct-topic metadata path from the earlier synthetic/queued-message fix, but the base adapter helper and adapter no-anchor fallback were missing the same routing.Related
Fixes #27139.
Related to #27114, #26945, #27462, and #27166.
This intentionally does not fall back to
message_thread_idalone for the no-anchor case; live Telegram DM-topic replies still keep the reply-anchor route, while synthetic/resumed sends usedirect_messages_topic_idwhen metadata has it.Test plan
uv run --extra messaging pytest -o addopts= tests/gateway/test_telegram_thread_fallback.py::test_base_gateway_metadata_marks_telegram_dm_topics_as_reply_fallback tests/gateway/test_telegram_thread_fallback.py::test_base_gateway_metadata_for_resumed_telegram_dm_topic_uses_direct_topic tests/gateway/test_telegram_thread_fallback.py::test_send_private_dm_topic_uses_direct_messages_topic_id tests/gateway/test_telegram_thread_fallback.py::test_send_uses_reply_fallback_for_hermes_dm_topics tests/gateway/test_telegram_thread_fallback.py::test_send_dm_topic_fallback_without_anchor_does_not_crash -q