Presence Intent added, Shard now takes too long to become ready
Hey, so today I got the guild presence intent added for my bot. However, simply including it in my presences causes the startup to fail.
Even without trying to actually do anything besides login, I get
Error [ShardingReadyTimeout]: Shard 0's Client took too long to become ready.
This is the case if I have 2 shards or 10 shards. For reference, my bot is in just over 4k servers.
These are the intents I'm now requesting when the failure occurs:
I already have access for the Server Members Intent, and everything works fine if I simply comment out GatewayIntentBits.GuildPresences (except of course I cannot receive the guildMemberAdd and guildMemberRemove events)
Please help!
npm list discord.js: discord.js@14.6.0
node -v: v16.13.024 Replies
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
The presences intent adds an initial payload of server members to the
identify call, meaning discord.js needs to process a lot more information per guild. I think you can address this by increasing the waitGuildTimeout ClientOption or possibly changing the caching options for presences/members using the makeCache optionI see -- thanks for the info. I am currently only default caching the things that are required to cache
But I'll try increasing the waitGuildTimeout
Btw is that in MS?
Yeah
How are you managing the shards, internal sharding?
Not internal sharding, no
If you're using the
ShardingManager you can also look at the timeout option for .spawn()Gotcha, is there any difference in using that vs the guild timeout? I guess one is at the guild level and one is at the shard?
I actually think the shard one is the one I meant to give you
Ah ok
Since thats what the error relates to
Right - yeah that seems to be having more of an effect (waiting longer anyway, we'll see if it fails or not 🤞 )
Hmm I think it worked, thank you @monbrey ! At least a few of the shards have successfully become ready. I'll try re-enabling some of my functionality and see if it is all good.
Kinda rough that it takes this long to start up though, heh
I guess this may consume a lot more memory now too, eh?
It should be okay if you're customising your caches correctly
But yeah it's going to be receiving nad handling presence events
Gotcha
Is it possible that just getting through the first startup was the hard part, perhaps it had a large backlog of data to process? It seems to be starting up much quicker on my next attempt
I c
Does enabling the presences intent somehow disable the members intent? I am now getting a bunch of errors
Cannot read properties of undefined (reading 'id')
from at GuildMemberRoleManager.get cache [as cache]
when trying to call members.get(userId)an undefined on the role manager usually suggests the everyone role is missing, which is an issue with the
Guilds intent
And you still cache the GuildManager and RoleManager so idkHmm ic -- yeah still trying to reproduce it locally, ofc this error seems to only consistently happen when I deploy to the server <a:Pepe_Cry:976852368274653265>
Hmm so upon further digging, it looks like this error is actually being thrown at
member.roles.cache.has(roleId.trim()) -- not sure if that changes anything or any other possibilities I should check.
Strangely this same call works fine in my local still. As soon as I deploy it to the server though, everything goes haywire 😦
I am finally able to reproduce something in my local -- it seems to be throwing this error message:
Error [GuildMembersTimeout]: Members didn't arrive in time.
Seems to happen the same if I send { withPresences: false } -- not really sure what the other FetchMembersOptions would do
Bump -- anyone with any ideas? Enabling the GatewayIntentBits.GuildPresences intent seems to be the only factor here, everything works fine without it (except I don't receive guildMemberAdd and guildMemberRemove events 😦 )Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
This process gets called a lot and is currently instantaneous... If the only solution is waiting longer I may just run all the "presences" stuff as a separate process.. Would really rather avoid that because running the bot in several instances is pretty resource intensive (and I'm already running it as two so the performace of interactions will be unaffected by the other processing)
Is there possibly a bug with the 
initially the issue was that I wasn't getting the event payloads for users leaving servers because that's the one that requires presence apparently. Also, I am caching the bare minimum because caching members absolutely crushes the memory usage and would require an even higher tier cost of hosting (already pretty darn expensive). I do store users membership/roles/etc in my DB, but part of my app's functionality makes it critical to be 100% accurate about this information. Perhaps I will find that now that I have enabled the presence intent and am running that on a separate server I no longer need to call members.fetch very often, but that kind of remains to be seen (strangely it seems like it's logging almost NO events when I have all the intents enabled...)
I agree that the documentation seems to imply that guild member remove doesn't require presence
But I've never seen it once fire, and my users are reporting that they are unable to leave servers (my web app shows which they are in the bot is aware of)
withPresences: false option? I would expect that to behave basically the same as not having the presences intent...
Sorry I gotta keep bumping this but I feel like there is potentially some bug here, possibly with my app ofc, maybe not with djs but would help to know how I could rule it out
If there's anyone out there with a verified bot, and also the Guild Members and Presence Update intents, can you possibly just try firing up an instance of your bot with the following intents
And then try to do a await guild.members.fetch() call against a server with a few thousand members and see if it takes a really really long time? If it doesn't it could indicate an issue with my code...
But I mean I'm doing basically nothing besides just that in my repro script so idk what that could be initially the issue was that I wasn't getting the event payloads for users leaving servers because that's the one that requires presence apparently. Also, I am caching the bare minimum because caching members absolutely crushes the memory usage and would require an even higher tier cost of hosting (already pretty darn expensive). I do store users membership/roles/etc in my DB, but part of my app's functionality makes it critical to be 100% accurate about this information. Perhaps I will find that now that I have enabled the presence intent and am running that on a separate server I no longer need to call members.fetch very often, but that kind of remains to be seen (strangely it seems like it's logging almost NO events when I have all the intents enabled...)
I agree that the documentation seems to imply that guild member remove doesn't require presence
But I've never seen it once fire, and my users are reporting that they are unable to leave servers (my web app shows which they are in the bot is aware of)And there are several stack overflow answers saying it is required for guildMemberUpdate and guildMemberRemove https://stackoverflow.com/questions/69021588/discord-js-guildmemberremove-doesnt-work-guildmemberadd-works-perfectly-fine for example
Stack Overflow
discord.js - guildMemberRemove doesn't work, guildMemberAdd works p...
Sorry if this is poorly formatted, I've never written a question on here before.
First of all, this is my first time writing anything in JavaScript, so this might be some dumb mistake I'm making th...
And caching all members of all the 4.2k servers my bot is in would be ridiculously expensive
It is only relatively rare I actually need the member data for any one specific server, and I need it at just one moment, but likely not again for a while
Just, across 4.2k it gets called quite frequently for different specific servers
Right so
guildMemberRemove requires GuildMembers
But to fire on uncached members you would also need to enable the GuildMember partial
Ah interesting
Wow so maybe I don't even need this intent I requested lol
I think this will solve the core of my issue, tysm for the help & bearing with me
Those stack overflow questions really got me on the wrong track, lmao
Ic - thank you for the detailed explanation
Confirming this solved my issue 100%. Thanks again everyone who helped me work thru this ❤️