You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Handling of site connection issues during outage. #2918
Currently, under somewhat specific circumstances the bot might result in few Cogs/Extensions not being loaded if site will drop the connection or otherwise will fail to return relevant information to the bot. Most notably the bot will not load filters cog, superstarify, reminders and python_news.
This issue happens with no indication of a failure to moderators as such bot might end up in a state where filters will be disabled and mods will be none the wiser.
The bot should:
Alert moderators that such a thing occurred (filters weren't loaded)
Potentially try to gracefully handle the issue and try to reconnect / retry later.
The cogs won't have been loaded because there was an unhandled error in the async cog_load function.
We should update cogs that rely on site being availalble during cog load to handle errors like this, and retry a few times, with some backoff logic, to be resiliant to temporary site outages.
If the bot still can't load the cogs after a number of attempts, we should then raise an error so that it appears in sentry and can be actioned.
We're working on addressing this issue in our fork by implementing two things:
(1) centralized extension load error detection that wraps Bot.load_extension() in try/except to catch and track failures that currently occur silently in async tasks, and
(2) Retry + exponential backoff logic implemented in each affected cog’s cog_load() (filters, superstarify, reminders, python_news) to handle temporary site/API unavailability. If retries are exhausted, the filters cog sends a moderator alert and re-raises the error so it surfaces in Sentry.
We’re also adding unit tests to cover retry and failure behavior for both parts. If there are concerns about this direction before we open the PR, we’d appreciate feedback.
Activity
ChrisLovering commentedon Feb 7, 2024
The cogs won't have been loaded because there was an unhandled error in the async cog_load function.
We should update cogs that rely on site being availalble during cog load to handle errors like this, and retry a few times, with some backoff logic, to be resiliant to temporary site outages.
If the bot still can't load the cogs after a number of attempts, we should then raise an error so that it appears in sentry and can be actioned.
rippyboii commentedon Feb 23, 2026
Hi,
I would like to work on this issue. If you have no problem with it, can you assign this one to me?
rippyboii commentedon Feb 26, 2026
We're working on addressing this issue in our fork by implementing two things:
(1) centralized extension load error detection that wraps
Bot.load_extension()intry/exceptto catch and track failures that currently occur silently in async tasks, and(2) Retry + exponential backoff logic implemented in each affected cog’s
cog_load()(filters, superstarify, reminders, python_news) to handle temporary site/API unavailability. If retries are exhausted, the filters cog sends a moderator alert and re-raises the error so it surfaces in Sentry.We’re also adding unit tests to cover retry and failure behavior for both parts. If there are concerns about this direction before we open the PR, we’d appreciate feedback.
jb3 commentedon Feb 26, 2026
That seems reasonable!