fix(cron): retry Telegram DM topic delivery with reply anchor on thread-not-found#23249
fix(cron): retry Telegram DM topic delivery with reply anchor on thread-not-found#23249devsart95 wants to merge 1 commit into
Conversation
…ad-not-found Bot API 10.0+ (server-side, ~2026-05-08) rejects sendMessage calls that use bare message_thread_id for private DM topics. The fix (PR NousResearch#22410) was applied to TelegramAdapter.send() in the gateway, but the cron delivery path in tools/send_message_tool.py::_send_telegram was not updated. When _send_telegram gets "Message thread not found" after including message_thread_id in the send kwargs, it now: 1. Sends a minimal placeholder message (no thread_id) to get a message_id that can serve as a reply anchor 2. Retries the actual message with message_thread_id + reply_to_message_id pointing to the placeholder 3. Deletes the placeholder (silent best-effort) This implements the three-mode routing from TelegramAdapter: - Forum/supergroup topics -> message_thread_id (unchanged) - Bot API DM topics -> direct_messages_topic_id (adapter only) - Hermes-created private DM topic lanes -> message_thread_id + reply_to_message_id anchor (new in tool) Fixes NousResearch#22773 X: @rojassartorio Co-authored-by: Rojas Sartorio <rojassartorio@users.noreply.github.com>
|
Thanks for working on this. I hit what looks like an adjacent cron-path gap while auditing a live Hermes deployment against current This PR appears to cover the standalone Current send_metadata = {"thread_id": thread_id} if thread_id else None
runtime_adapter.send(chat_id, text_to_send, metadata=send_metadata)For explicit Telegram DM-topic cron deliveries such as Cron then falls back to the standalone path, so this may not fully break delivery, but it creates repeated warning noise and makes the first attempted path fail even though the target had enough information in the cron I have a small local patch + focused tests for Would you prefer that patch as an additional commit here, or as a separate small PR linked to #22773? |
Summary
When a cron job delivers output to a Telegram DM topic via
telegram:chat_id:thread_id, the_send_telegramfunction insend_message_tool.pysends with baremessage_thread_id— which Bot API 10.0+ (server-side change ~2026-05-08) rejects for private chats with topics. The gateway adapter was fixed in PR #22410, but the cron delivery path was missed.Root cause
_send_telegram()at line 787-808 setsthread_kwargs["message_thread_id"]for topic delivery. Bot API 10.0 requiresmessage_thread_id+reply_to_message_id(anchor) together for private DM topics. Without the anchor, the API returns "Message thread not found".Fix
Added an
elifbranch in the existing send-error handler: when the error contains "thread not found" andmessage_thread_idwas set:.) to the main chat to get amessage_idmessage_thread_id+reply_to_message_idpointing to the placeholderIf the anchor retry also fails, the original error is re-raised so the caller sees the root cause.
Three-mode routing now covered
message_thread_iddirect_messages_topic_id)direct_messages_topic_idmessage_thread_id+reply_to_message_idFiles changed
tools/send_message_tool.py— +42 lines in_send_telegram()error handlerFixes #22773
X: @rojassartorio