Description
In a Telegram group, /new@otherbot addresses a different bot. The three Python Telegram samples can nevertheless handle it as this bot's /new command and reset this bot's group conversation. This matters when the bot receives group messages addressed to others, such as when it is a group administrator or privacy mode is disabled.
Steps to reproduce
- Configure one of the Telegram samples as a bot that receives group messages.
- Send
/new@otherbot to a group containing that bot.
- Inspect this bot's command path. The parser produces
/new, and the sample dispatches that value to its reset handler.
The current main source at 2024d4df4 establishes the path:
| Stage |
Current behavior |
telegram_command |
Matches the optional @bot suffix but returns only the command name and arguments. For /new@otherbot, the result is /new. |
| Local polling sample |
handle_update passes that result to handle_command; its /new branch calls state.session_store.delete(session_id). |
| Local webhook sample |
The same dispatch reaches state.session_store.delete(session_id) inside the per-chat lock. |
| Foundry-hosted sample |
handle_telegram_update dispatches /new to _send_command_response, which calls runtime.history.clear(session_id). |
Expected behavior: Ignore commands addressed to another bot before command dispatch or model invocation. Continue handling /new and /new@thisbot for this bot.
Actual behavior: /new@otherbot loses its target suffix and follows this bot's /new path. Other commands addressed elsewhere can similarly be handled or fall through to the agent.
The parser output was reproduced directly against the earlier c804f32c9 revision. The same parser and dispatch logic is present in 2024d4df4. The session deletion and history clearing above follow from these source call paths; I have not run the samples in a live Telegram group.
Code Sample
from agent_framework_hosting_telegram import telegram_command
update = {
"message": {
"chat": {"id": -123, "type": "supergroup"},
"from": {"id": 42},
"text": "/new@otherbot",
}
}
assert telegram_command(update) == "/new" # Current behavior on main.Error Messages / Stack Traces
None. The parser returns a valid-looking command, so the failure is a wrong action rather than an exception.
Package Versions
agent-framework-hosting-telegram 1.0.0a260730 and agent-framework-hosting 1.0.0a260730, from repository source.
Python Version
Python 3.13.2 on Windows for the direct parser reproduction and local tests.
Additional Context
One compatible fix is an optional bot_username parameter for telegram_command, with each sample supplying its own username and returning early for a mismatch. The current behavior when callers omit a username is documented; changing that default would be a separate compatibility decision. I am taking on this fix in #8803 and welcome feedback on the public parameter's shape.
A new target-aware parser test failed against the original c804f32c9 code with TypeError: telegram_command() got an unexpected keyword argument 'bot_username' (1 failed). That pre-fix failure establishes the missing API support; it does not claim a live group-session reset. The proposed fix has passing mocked tests for all three sample paths.
I searched open and closed issues and PRs for telegram, telegram_command, otherbot, and bot-suffixed on 2026-09-28 and found no report or PR for target matching. #6588/#7047 introduced the helper and local samples; #7883 added the Foundry-hosted sample. Those items do not cover this routing defect.
Description
In a Telegram group,
/new@otherbotaddresses a different bot. The three Python Telegram samples can nevertheless handle it as this bot's/newcommand and reset this bot's group conversation. This matters when the bot receives group messages addressed to others, such as when it is a group administrator or privacy mode is disabled.Steps to reproduce
/new@otherbotto a group containing that bot./new, and the sample dispatches that value to its reset handler.The current
mainsource at2024d4df4establishes the path:telegram_command@botsuffix but returns only the command name and arguments. For/new@otherbot, the result is/new.handle_updatepasses that result tohandle_command; its/newbranch callsstate.session_store.delete(session_id).state.session_store.delete(session_id)inside the per-chat lock.handle_telegram_updatedispatches/newto_send_command_response, which callsruntime.history.clear(session_id).Expected behavior: Ignore commands addressed to another bot before command dispatch or model invocation. Continue handling
/newand/new@thisbotfor this bot.Actual behavior:
/new@otherbotloses its target suffix and follows this bot's/newpath. Other commands addressed elsewhere can similarly be handled or fall through to the agent.The parser output was reproduced directly against the earlier
c804f32c9revision. The same parser and dispatch logic is present in2024d4df4. The session deletion and history clearing above follow from these source call paths; I have not run the samples in a live Telegram group.Code Sample
Error Messages / Stack Traces
None. The parser returns a valid-looking command, so the failure is a wrong action rather than an exception.
Package Versions
agent-framework-hosting-telegram1.0.0a260730 andagent-framework-hosting1.0.0a260730, from repository source.Python Version
Python 3.13.2 on Windows for the direct parser reproduction and local tests.
Additional Context
One compatible fix is an optional
bot_usernameparameter fortelegram_command, with each sample supplying its own username and returning early for a mismatch. The current behavior when callers omit a username is documented; changing that default would be a separate compatibility decision. I am taking on this fix in #8803 and welcome feedback on the public parameter's shape.A new target-aware parser test failed against the original
c804f32c9code withTypeError: telegram_command() got an unexpected keyword argument 'bot_username'(1 failed). That pre-fix failure establishes the missing API support; it does not claim a live group-session reset. The proposed fix has passing mocked tests for all three sample paths.I searched open and closed issues and PRs for
telegram,telegram_command,otherbot, andbot-suffixedon 2026-09-28 and found no report or PR for target matching. #6588/#7047 introduced the helper and local samples; #7883 added the Foundry-hosted sample. Those items do not cover this routing defect.