Fix bot startup conflict by dropping pending Telegram updates#11
Fix bot startup conflict by dropping pending Telegram updates#11
Conversation
Add drop_pending_updates=True to run_polling() to clear any pending updates from Telegram's servers before starting to poll. This helps resolve "Conflict: terminated by other getUpdates request" errors when restarting the bot after a previous instance wasn't properly stopped. Co-authored-by: poseidonchan <43901301+poseidonchan@users.noreply.github.com>
|
@codex[agent] Does this PR solve the issue? |
|
To use Codex here, create an environment for this repo. |
|
@codex does this PR addresses the issue? |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: c62fc0e7fb
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
src/tgcodex/bot/app.py
Outdated
| # errors when restarting the bot after a previous instance wasn't properly stopped. | ||
| app.run_polling( | ||
| allowed_updates=["message", "callback_query"], | ||
| drop_pending_updates=True, |
There was a problem hiding this comment.
Passing drop_pending_updates=True in the run_bot polling path causes Telegram to discard every queued update before the bot starts, so any messages/callbacks sent while the bot is down (e.g., during a restart or crash recovery) are silently lost. This introduces user-visible data loss on every startup, which is a broad behavioral regression compared to previous behavior where queued updates were processed after recovery.
Useful? React with 👍 / 👎.
|
@copilot it seems the PR does not pass the code review. |
Address review feedback: drop_pending_updates=True caused data loss by discarding all queued updates on every startup. Instead, use bootstrap_retries=3 to handle "Conflict" errors by retrying, allowing the old polling connection to timeout gracefully without losing messages. Co-authored-by: poseidonchan <43901301+poseidonchan@users.noreply.github.com>
Addressed the review feedback in commit 98958e8. The original fix using |
|
@codex review the latest fixes |
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 98958e8583
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| # to timeout gracefully without dropping pending updates. | ||
| app.run_polling( | ||
| allowed_updates=["message", "callback_query"], | ||
| bootstrap_retries=3, |
There was a problem hiding this comment.
The new startup fix is still too short-lived: the comment right above this call notes Telegram can keep the previous long-poll connection alive for about 10 seconds, but bootstrap_retries=3 gives up after only three bootstrap failures, so a routine quick restart can still terminate with the same conflict error. In that scenario the process may briefly look healthy and then exit, leaving startup unreliable; this should use a retry budget that actually spans the lingering poll window (or indefinite retries).
Useful? React with 👍 / 👎.
Add(reverted - causes data loss)drop_pending_updates=Trueto clear pending updatesbootstrap_retries=3to retry on conflict, allowing old connections to timeout gracefullySummary
This PR fixes the "Conflict: terminated by other getUpdates request" error that occurs when starting the bot after a previous instance wasn't properly stopped.
Root Cause
When a bot instance is stopped, Telegram's servers may still have an active long-polling connection that times out after ~10 seconds. Starting a new instance during this window causes a conflict error.
Fix
Use
bootstrap_retries=3in therun_polling()call. This allows the bot to retry the connection if it encounters a conflict error, giving time for the previous polling connection to timeout gracefully.Why Not
drop_pending_updates?The initial fix used
drop_pending_updates=True, but code review correctly identified that this causes data loss: all messages/callbacks sent while the bot was down would be silently discarded. The retry approach preserves all pending updates while still handling the conflict error.Original prompt
💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.