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
When a RESUME gateway event is received during the chunking process, it may sometimes interrupt the task, resulting in the bot becoming indefinitely stuck in a false .is_ready() state.
Reproduction Steps
Although, I am not sure what caused this; the problem began occurring unexpectedly following an update to the latest library version. There were no code changes or other apparent triggers on my end.
Minimal Reproducible Code
Expected Results
For the bot to complete the guild chunking task and successfully trigger the on_ready event.
Actual Results
Shard3:INFO 2025-02-26 02:43:56.964 logging(callHandlers) Shard ID 3 has successfully RESUMED session 753a5792b68e823dc16ff3cde7576bef.
Shard3:ERROR 2025-02-26 02:44:53.372 __main__(loop_exception_handler) Shard 3: Unhandled exception caught in the event loop: <Task finished name='Task-39' coro=<ConnectionState._delay_ready() done, defined at ..../micromamba/envs/bleed/lib/python3.12/site-packages/discord/state.py:608> exception=ConnectionResetError('Cannot write to closing transport')> Task exception was never retrieved. Extra: {'message': 'Task exception was never retrieved', 'exception': ConnectionResetError('Cannot write to closing transport'), 'future': <Task finished name='Task-39' coro=<ConnectionState._delay_ready() done, defined at .../micromamba/envs/bleed/lib/python3.12/site-packages/discord/state.py:608> exception=ConnectionResetError('Cannot write to closing transport')>}
- Python v3.12.4-final
- discord.py v2.5.0-final
- aiohttp v3.9.0
- system info: Linux 5.15.0-125-generic #135-Ubuntu SMP Fri Sep 27 13:53:58 UTC 2024
Checklist
I have searched the open issues for duplicates.
I have shown the entire traceback, if possible.
I have removed my token from display, if visible.
Additional Context
Each process handles a significant load that may be relevant to this issue:
~600 guilds per shard (average)
~2.5 million users per shard (range: 1.9M-3M)
These metrics are considerably higher than those of most standard bots, and our guild-to-user ratio is notably divergent from average bots. Our consumer base primarily consists of large servers ranging from 10,000 to 700,000 members per guild, creating a usage pattern that's significantly different from typical bots. This unusual guild-to-user ratio may explain why this issue hasn't been previously reported by other users.
A temporary solution, by using the jishaku eval command, running bot._connection._ready_task = asyncio.create_task(bot._connection._delay_ready()) does resume the chunking process and fires on_ready.
The text was updated successfully, but these errors were encountered:
Summary
When a RESUME gateway event is received during the chunking process, it may sometimes interrupt the task, resulting in the bot becoming indefinitely stuck in a false .is_ready() state.
Reproduction Steps
Although, I am not sure what caused this; the problem began occurring unexpectedly following an update to the latest library version. There were no code changes or other apparent triggers on my end.
Minimal Reproducible Code
Expected Results
For the bot to complete the guild chunking task and successfully trigger the on_ready event.
Actual Results
Intents
guilds, members, moderation, expressions, integrations, webhooks, invites, voice_states, presences, guild_messages, dm_messages, guild_reactions, dm_reactions, guild_typing, dm_typing, message_content, guild_scheduled_events, auto_moderation_configuration, auto_moderation_execution, guild_polls, dm_polls
System Information
Checklist
Additional Context
Each process handles a significant load that may be relevant to this issue:
~600 guilds per shard (average)
~2.5 million users per shard (range: 1.9M-3M)
These metrics are considerably higher than those of most standard bots, and our guild-to-user ratio is notably divergent from average bots. Our consumer base primarily consists of large servers ranging from 10,000 to 700,000 members per guild, creating a usage pattern that's significantly different from typical bots. This unusual guild-to-user ratio may explain why this issue hasn't been previously reported by other users.
A temporary solution, by using the
jishaku eval
command, runningbot._connection._ready_task = asyncio.create_task(bot._connection._delay_ready())
does resume the chunking process and fires on_ready.The text was updated successfully, but these errors were encountered: