Skip to content

fix(telegram): request guest_message in allowed_updates for guest mode - #68061

Closed
elphamale wants to merge 1 commit into
NousResearch:mainfrom
elphamale:fix/telegram-guest-message-allowed-updates
Closed

fix(telegram): request guest_message in allowed_updates for guest mode#68061
elphamale wants to merge 1 commit into
NousResearch:mainfrom
elphamale:fix/telegram-guest-message-allowed-updates

Conversation

@elphamale

@elphamale elphamale commented Jul 20, 2026

Copy link
Copy Markdown

Summary

  • Guest mode (Bot API 10.0 `guest_message` @mentions from chats the bot isn't a member of) wasn't working: `allowed_updates=Update.ALL_TYPES` at both `start_polling()`/`start_webhook()` call sites tells Telegram to send every update type PTB has a typed field for — but PTB doesn't have one for `guest_message` yet, so it's excluded from that hardcoded list and Telegram drops it server-side before it ever reaches the process.
  • No exception, no log line, nothing — the `_handle_guest_message_update` TypeHandler registers fine and just never fires, from any chat, indistinguishable from a backend outage.
  • Confirmed live via `getWebhookInfo`: `allowed_updates` was missing `guest_message` even though `getMe` reports `supports_guest_queries: true`.
  • Note on history: `git log -S` shows this exact `allowed_updates=Update.ALL_TYPES` line has been present unchanged since the 2026-06-20 platform-adapter migration (`5600105`), with `python-telegram-bot` pinned at `22.6` throughout — so this isn't a new regression from a dependency bump. It's unclear exactly how long guest mode was actually broken for in practice; treat this as "found broken and fixed today," not a claim about when it started.
  • Fix: explicitly append `"guest_message"` to the allowed_updates list at both call sites, via a shared `_ALLOWED_UPDATES_WITH_GUEST` constant (getattr-guarded against `Update.ALL_TYPES` for test doubles that stub `Update` minimally).
  • No test coverage existed for `allowed_updates` at all before this, which is how it shipped unnoticed. Added a regression test pinning the constant's content and that no call site bypasses it.

Test plan

  • New regression test: `tests/gateway/test_telegram_guest_message_allowed_updates.py` (2 tests)
  • Full `tests/gateway/` sweep via `run_tests_parallel.py`: clean except one pre-existing, unrelated Honcho mtime-cache test that also fails on pristine `origin/main`
  • Verified live post-deploy: `getWebhookInfo` on the running bot now shows `guest_message` in `allowed_updates`

PTB's Update.ALL_TYPES is a hardcoded enumeration of update kinds PTB
has a typed field for. Bot API 10.0's guest_message isn't one of them
(see _handle_guest_message_update's docstring — PTB doesn't have a
typed field for it yet, the raw payload arrives via
update.api_kwargs["guest_message"]). Passing Update.ALL_TYPES verbatim
as allowed_updates to start_polling()/start_webhook() tells Telegram
to send every OTHER update type and drop guest_message server-side,
before it ever reaches this process.

The _handle_guest_message_update TypeHandler registers without error
and no exception fires anywhere — the bot just silently never receives
a guest @mention, from any chat, indistinguishable from an outage.
Confirmed live via getWebhookInfo: allowed_updates was missing
guest_message even though getMe reported supports_guest_queries: true.

Fixes it by explicitly appending "guest_message" to the allowed_updates
list at both call sites (polling and webhook), getattr-guarded since
some tests inject a minimal fake `telegram` module (Update = object)
that has no ALL_TYPES attribute. No test coverage existed for
allowed_updates at all before this, which is how it shipped unnoticed;
added a regression test pinning both the constant's content and that
no call site bypasses it.
@alt-glitch alt-glitch added type/bug Something isn't working P2 Medium — degraded but workaround exists comp/plugins Plugin system and bundled plugins platform/telegram Telegram bot adapter sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages labels Jul 20, 2026
@elphamale

Copy link
Copy Markdown
Author

Folded into #56476 (the PR whose own commit introduced the gap this fixes — see that PR's own commit history for the fixup) rather than shipping the feature broken and following up separately. #56477 rebased on top to keep the stack intact. Closing this one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

comp/plugins Plugin system and bundled plugins P2 Medium — degraded but workaround exists platform/telegram Telegram bot adapter sweeper:risk-message-delivery Sweeper risk: may drop, duplicate, misroute, or suppress messages type/bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants