fix(telegram): recover when polling updater stops while process stays alive (#55769) - #55921
Merged
Conversation
… alive The polling heartbeat's pending-update probe treated a stopped updater (running=False) as "someone else's job" and silently reset its counter, so a long-poll task that disappears with no reconnect in flight was never recovered. get_me() on the general request path stays healthy, so neither PTB's error_callback nor the connectivity probe ever fires — the gateway keeps running but stops receiving messages indefinitely (#55769). Detect the stopped-updater case directly in _probe_pending_updates and feed it into the existing _handle_polling_network_error ladder, debounced over two consecutive probes so a just-starting updater or the brief stop()->start_polling() window of an in-flight reconnect never trips it.
alt-glitch
added
type/bug
Collaborator
Duplicate of #55905, which is the same salvage of #55789 and was merged (2026-06-30) -- the stopped-updater recovery branch ( |
13 tasks
This was referenced Aug 3, 2026
Closed
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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 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
The Telegram gateway can silently stop receiving messages while the process stays alive (systemd green, threads healthy, send path fine) — no logs, no errors — until manually restarted (#55769). This makes the gateway self-heal from that state.
Root cause: the polling heartbeat's
_probe_pending_updatesalready handled a wedged-but-running long-poll consumer, but treated a fully stopped updater (running == False, no reconnect in flight) as "someone else's job" — it reset its counter and returned. Becauseget_me()on the general request path stays healthy, neither PTB'serror_callbacknor the connectivity heartbeat ever fires. Result: process alive, send path fine, polling dead, indefinitely.Changes
plugins/platforms/telegram/adapter.py—_probe_pending_updatesnow detectsupdater.running == Falseand feeds it into the existing_handle_polling_network_errorrecovery ladder (stop → drain pool →start_polling). Debounced over two consecutive probes via a new_polling_not_running_count. The in-flight-reconnect guard is moved ahead of the updater check so the reconnect's own transientstop()→start_polling()window (whererunningis briefly False) can't false-trip. No new restart machinery, no new config keys, no new env vars.tests/gateway/test_telegram_pending_update_probe.py— replaced the test that encoded the old buggy "stopped updater = no-op" assumption with coverage for: single stopped probe does not escalate, two consecutive stopped probes trigger recovery, a recovered (running) updater resets the counter, and an in-flight reconnect suppresses escalation.Validation
running=False)Salvaged from @PRATHAMESH75's PR #55789, cherry-picked onto current
mainwith authorship preserved.Infographic
Nous Research