Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

on_shard_ready(shard_id) Not firing. #2541

Open
ChillFish8 opened this issue Jan 27, 2020 · 6 comments
Open

on_shard_ready(shard_id) Not firing. #2541

ChillFish8 opened this issue Jan 27, 2020 · 6 comments

Comments

@ChillFish8
Copy link

@ChillFish8 ChillFish8 commented Jan 27, 2020

Summary

on_shard_ready(shard_id) - This function is not firing when it should, it seems to only fire for some bot tokens and not others. on_ready() however, is firing reliably every time instead of on_shard_ready(shard_id)

Context:

  • using AutoShardedClient()
  • Shardcount ranging between 1 and 10
  • Tested code on 4 diffrent bot applications non successfully working appart from 1 that has no issues.

Reproduction Steps

  1. Call AutoShardedClient. I used this inside of class see Here for the full paste of that class.

  2. Run the bot.

  3. see code block Here Note: Bot object is the Client object still.

Expected Results

You would expect on_shard_ready(shard_id) to fire once a shard is ready.
e.g.
[Client Running] - Shard: [0] [Online] - Ping: 101ms | Test bot (572022204243012608)
[Client Running] - Shard: [1] [Online] - Ping: 101ms | Test bot (572022204243012608)

Actual Results

on_shard_ready(shard_id) does not fire at all, instead on_ready() when attempted fires at every shard connection.

Console Log:
[20/01/27 | 19:05:34] Generated Client! shards: 1
[20/01/27 | 19:05:34] Client Initialised!
Please Enter your bot token:
[20/01/27 | 19:05:37] Starting Bot...

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.

System Information

  • Python v3.7.4-final
  • discord.py v1.3.1-final
  • aiohttp v3.6.2
  • websockets v8.1
  • system info: Windows 10 10.0.17763
@PredaaA
Copy link
Contributor

@PredaaA PredaaA commented Jan 28, 2020

I am having a similar issue, with same context as that one.
What's actually happening for me is that on_ready is fired before all on_shard_ready are fired. And it's in a completely random order, sometimes it can do that when only one shard has been connected, but also after 5 shards connected, for a total of 9 shards. So as long as ready event has been dispatched, all missing shards are waiting forever on_shard_ready.

However, after looking at changelogs of discord.py 1.3, I saw changes to those two events, so I tried without PR #2504, and everything was working fine.

@ChillFish8
Copy link
Author

@ChillFish8 ChillFish8 commented Jan 28, 2020

I actually have attempted both also on a bare bones test bed on a new venv with a fresh install of d.py:

fetch_offline_members=True

and

fetch_offline_members=False

Both still fail to fire for on_shard_ready() and on_ready() is being fired still. (Tested the events seperately)

@aiden2480
Copy link

@aiden2480 aiden2480 commented Jan 28, 2020

Just a quick note that your second example contains your bot token *.*

@ChillFish8
Copy link
Author

@ChillFish8 ChillFish8 commented Jan 28, 2020

was regenerated before being sent and i editied it with a link that didnt directly show it, good catch tho

@NCPlayz
Copy link
Contributor

@NCPlayz NCPlayz commented Jan 28, 2020

However, after looking at changelogs of discord.py 1.3, I saw changes to those two events, so I tried without PR #2504, and everything was working fine.

Thought I'd reply. shard_ready is dispatched per shard if _ready_state.guilds is populated in the first place. I tested out a few variations of the code changes to verify if it was actually my PR, or something else.

Tests

With _fetch_offline as True:

  1. cd9135b and f95ccf5 (Normal) - No guilds are in _ready_state.guilds before Line 1063 is executed. (Verified 10 times)
  2. (Revert both changes) - No guilds are in _ready_state.guilds before the same line (in the old commit). (Verified 10 times)

With _fetch_offline as False:

  1. cd9135b and f95ccf5 (Normal) - No guilds are in _ready_state.guilds before Line 1063 is executed. (Verified 10 times)
  2. (Revert both changes) - shard_ready wasn't ever dispatched in the first place. (Verified 10 times)

These all seemed to have a correlation of not ever receiving the guilds before shard_ready were dispatched so I decided to see if guild_create was even dispatched by Discord.

With cd9135b and f95ccf5:

  1. _fetch_offline as True - 4 guilds are created before Line 1063, 2 guild after ready was dispatched (relatively large servers). All guilds are available. They are not added to _ready_state.guilds before ready.
  2. _fetch_offline as False - Same as above.

So, I decided to look at where parse_guild_create added the guild to _ready_state.guilds.

Conclusion

Guilds are only added to _ready_state.guilds if they're large guilds, and the large guilds don't seem to be created until after ready has been dispatched, hence why I think shard_ready was never dispatched. Large guilds also aren't added after ready since _ready_state is purely for before ready being dispatched and subsequently deleted after it is dispatched, so it will raise an AttributeError at Line 761.

Feel free to correct me on this.

@ChillFish8
Copy link
Author

@ChillFish8 ChillFish8 commented Jan 29, 2020

After some more testing and with the new commit it seems that on_shard_ready() is firing reliably for large bots that need sharding which is fine for what I need now, altho makes testing on a one guild test bot impossible to use on_shard_ready() but that can be solved by just using a basic count system I guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.