Discord.py: on_ready doesn't fire when bot=False

[pappabewar]

Summary

When client is ran with bot=False, on_ready never fires

Reproduction Steps

Run anything with bot=False

I ran

client = discord.AutoShardedClient(fetch_offline_members=False)
client.run('token', bot=False)

Expected Results

Client connects and on_ready fires

Actual Results

Log shows websocket events for messages, reactions etc. But on_ready never fires

Checklist

• [x] I have searched the open issues for duplicates.
• [x] I have shown the entire traceback, if possible.
• [x] I have removed my token from display, if visible.

System Information

• Python v3.7.4-final
• discord.py v1.3.0-alpha
  
  
  
  • discord.py pkg_resources: v1.3.0a2132+g89bfd9c
  
  
• aiohttp v3.5.4
• websockets v6.0
• system info: Windows 10 10.0.18362

[Zomatree]

the ready event takes a long time for discord to send, also sharding for a user account is pointless and you should not selfbot as its against the discord TOS and can get you banned.

[pappabewar]

Left it running for a couple of minutes, here's the tail of the log

[Phxntxm]

If discord ain't sending READY for userbots that sucks ¯\_(ツ)_/¯

Reminder, as the last post mentions, userbots are against the TOS.

[pappabewar]

If discord ain't sending READY for userbots that sucks ¯_(ツ)_/¯

Reminder, as the last post mentions, userbots are against the TOS.

I am well aware, however, this library supports it

[Phxntxm]

This library supports what the API supports. If the gateway isn't sending the READY event then....again, that sucks, but what do you want us to do about it? The library dispatches the events that are received, it's not gonna go "hey discord you forgot to send us READY for something that's not allowed! You should do that!"

[pappabewar]

This library supports what the API supports. If the gateway isn't sending the READY event then....again, that sucks, but what do you want us to do about it? The library dispatches the events that are received, it's not gonna go "hey discord you forgot to send us READY for something that's not allowed! You should do that!"

I don’t know what on_ready is, why do we even need it? If i’m getting messages and reactions etc over the websocket then i’m happy...

[the-white-light]

This seems to be a very recent change. on_ready _previously_ worked for bot=false.

[numbermaniac]

I don’t know what on_ready is, why do we even need it?

If you don't know what on_ready is, then why does this issue even matter?

[the-white-light]

It matters to other people who use on_ready.

[Gorialis]

I have attempted and failed to reproduce this issue on my end. However, it is apparent that the Discord websocket flow for chunking guilds has changed for users. It's possible you are not getting the on_ready event because these chunking differences cause the lib to fail to detect that everything is loaded.

Support for userbots in this library has been low priority ever since Discord staff made strong stances against their usage, and for the most part development on this feature of the library has been stopped ever since Discord officially released a statement on it.

The guild chunking flow is also projected to change for bots - if the changes made closely resemble the ones currently applying to users, it may be the case that this bug will get tangentially fixed when the fix for full bots is made, whenever that update to the websocket happens. However, the guild chunking flow for bots is already vastly more complicated than the flow for users, taking into account sharding and the much higher guild cap - so it's not guaranteed the changes made on Discord's end will be the same, nor the fix on the library's end.

For the most part, continued support for userbots by this library has mostly been third party (that is, individual people have been reverse engineering functionality and PRing it in - see #2254, #1768). As such, this is probably the most likely way this will get a fix, if at all. Since the user API has no official documentation (since its use is discouraged), the best way to go about this if you want to take this on yourself would probably be to set up logging and use a websocket inspector to figure out how the new flow works - Firefox Developer Edition and new versions of Chrome have tools that can help with this.

The only real closing note I can give on this is, well, don't use userbots. Discord has an official stance on them now, and the reasons to use them besides for nefarious purposes decreases day by day. We only support them here mainly as a remnant of when it was the only option. Modern bots get a lot of privileges over user accounts nowadays - it's a good idea to use them!

[atillabyte]

I wouldn't consider archiving messages as is the case with 'DiscordChatExporter' to be a nefarious usage. As far as I'm aware, it's against the ToS to use self bots to make actions on behalf of the user. The former would not apply, nor would simply listening to messages apply.

[SilicalNZ]

It is irrelavent as to what you consider to be nefarious usage and your awareness to the actual statements is outdated. Discords stance against self bots is very clear and all encompassing, simply stated "Not allowed".

As for what DiscordChatExplorter accomplishes, that is mostly provided through Channel.history(fetch=None)

[atillabyte]

Thank you for stating the obvious consensus amongst those who haven't spoken to any staff member on the subject. If you'd like to be useful instead of hostile, feel free to provide citations.

The Terms of Service are generalized for legality sake, it isn't a representation of how the company will react in every circumstance. I've heard from others that, after having spoken to a staff member, they were informed that those who use self-bots for what _they_ consider nefarious usage would risk having their accounts terminated, and those who don't simply would not.

"The Company reserves the right to refuse any user access to the Services without notice for any reason, including but not limited to a violation of the Terms."

"You agree not to (and not to attempt to) (i) use the Service for any use or purpose other than as expressly permitted by these Terms;
(iii) use data mining, robots, spiders, or similar data gathering and extraction tools on the Service."

I'm aware of what "DiscordChatExplorter" as you call it, does. I'd also point out that the Terms of Service aren't "irrelavent" to it either - it counts as scraping, or does it? I think you'll find that these questions could be answered by a staff member with much more clarity. The only information I've been able to gather as to WHY self-bots are forbidden are that they bypass the normal rate limits imposed upon bots and they are capable of automating user activities (i.e. adding friends). "DiscordChatExplorter" attempts to abide by the rate limits, and does not automate the user insofar as it doesn't cause any changes to anything.

[gogurtenjoyer]

If you'll only accept answers from staff members, what is the point of discussing it here at such length?

[IAmTomahawkx]

If you'd like a response from staff, how bout https://cdn.discordapp.com/attachments/381963689470984203/382387651162144779/unknown.png

[atillabyte]

Thank you, IAmTomahawkx. It doesn't specify what "a lot of things" are but at the very least it's pertinent information rather than unwarranted hostility.

I've never heard of anyone being banned for using the aforementioned tool to export chat logs. The "very clear" stance has a whole lot of very not clear enforcement decisions.

[IAmTomahawkx]

this is discord. literally nothing is consistent

[SilicalNZ]

Whatever you read to be "hostility" is in your own head.

Im going to ignore your focus on a typo, as it is not something so important like you make it out to be.

Gorialis provided an official statement. So why would I repost that.

A discord decision does not need reasons or explanation, they own their platform and may admin it in anyway they like. Finding the reasons as to why or their ability to enforce rules. Is in fact irrelevant to anything that this library represents. So long as the rules are clear, which they are in this regard, there is no room for interpretation and therefore no reason to support it.

You may contact Discord ToS if you require further clarity on this matter.

[SirNapkin1334]

Can this not be a discussion of the legality of selbots, and just be...a bug? A bug that should be squashed, or, if not, at least noted in the documentation?

[ItWasAllIntended]

A note in the documentation seems to be the most apt solution especially as this isn't a bug in the first place. The Discord.py events closely follow the ones dispatched by Discord. Deviation from this to support a usecase disallowed by Discord themselves is just silly

[Kr4ken-9]

If you are interested in documenting this behavior you might also be interested to know that on_ready is in fact called when logging in as a user, as long as the user is not fetching offline members. I suspect this is related to offline members being hidden from regular users, so I assume they shouldn't be fetching offline members anyway.

I think the OP was very close to avoiding this issue altogether (you can see they disabled fetching offline members), but they opted to use the AutoShardedClient for whatever reason.

[pappabewar]

Still doesn't work without autosharded client

Edit:
Updated to latest discord.py, and I can see on_ready firing now

[Kr4ken-9]

I'm glad you got it working! I would avoid using discord.py on any discord account you care about, because discord.py tells discord at every opportunity that you are using a bot library through HTTP Headers among other things. I would imagine discord takes note of this and flags your account, since they apparently aren't friendly to self-bots.

[pappabewar]

I'm glad you got it working! I would avoid using discord.py on any discord account you care about, because discord.py tells discord at every opportunity that you are using a bot library through HTTP Headers among other things. I would imagine discord takes note of this and flags your account, since they apparently aren't friendly to self-bots.

I understand that it would send discord.py user agent when HTTP requests are being made, but are there any things over the websocket that discord py sends that identifies its self as a bot?

[Kr4ken-9]

https://github.com/Rapptz/discord.py/blob/master/discord/gateway.py#L302
This is the only thing I found sent over the websocket, aptly named IDENTIFY

[FichteFoll]

To anyone reading this later, use fetch_offline_members=False to have on_ready fired after successfully connecting.