#Presence Intent added, Shard now takes too long to become ready

60 messages · Page 1 of 1 (latest)

acoustic oxide
#

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:

intents: [
  GatewayIntentBits.Guilds,
  GatewayIntentBits.GuildMessages,
  GatewayIntentBits.GuildMembers,
  GatewayIntentBits.GuildPresences,
]

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: [email protected]
node -v: v16.13.0

halcyon bough
#

• What's your exact discord.js npm list discord.js and node node -v version?
• Post the full error stack trace, not just the top part!
• Show your code!
• Explain what exactly your issue is.
• Not a discord.js issue? Check out #useful-servers.

limpid spoke
#

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 option

acoustic oxide
#

I see -- thanks for the info. I am currently only default caching the things that are required to cache

'GuildChannelManager',
'PermissionOverwriteManager',
'RoleManager',
'GuildManager',
'ChannelManager',

But I'll try increasing the waitGuildTimeout

#

Btw is that in MS?

limpid spoke
#

Yeah

#

How are you managing the shards, internal sharding?

acoustic oxide
#

Not internal sharding, no

limpid spoke
#

If you're using the ShardingManager you can also look at the timeout option for .spawn()

acoustic oxide
#

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?

limpid spoke
#

I actually think the shard one is the one I meant to give you

acoustic oxide
#

Ah ok

limpid spoke
#

Since thats what the error relates to

acoustic oxide
#

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 @limpid spoke ! 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?

limpid spoke
#

It should be okay if you're customising your caches correctly

#

But yeah it's going to be receiving nad handling presence events

acoustic oxide
#

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

outer halo
#

doubtful, there is no backlog for such things

acoustic oxide
#

I c

acoustic oxide
#

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)

limpid spoke
#

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 idk

acoustic oxide
#

Hmm ic -- yeah still trying to reproduce it locally, ofc this error seems to only consistently happen when I deploy to the server Pepe_Cry

acoustic oxide
#

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 😦

acoustic oxide
#

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.

acoustic oxide
#

Seems to happen the same if I send { withPresences: false } -- not really sure what the other FetchMembersOptions would do

acoustic oxide
#

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 😦 )

royal dove
#

fwiw, I had issues with timeouts, and just added a longer wait time in the .spawn() call of the sharding manager, and worked for me.

true magnetBOT
lethal wind
#

Use the time option

acoustic oxide
#

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 withPresences: false option? I would expect that to behave basically the same as not having the presences intent...

acoustic oxide
#

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

intents: [
  GatewayIntentBits.Guilds,
  GatewayIntentBits.GuildMessages,
  GatewayIntentBits.GuildMembers,
  GatewayIntentBits.GuildPresences,
]

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...

acoustic oxide
#

But I mean I'm doing basically nothing besides just that in my repro script so idk what that could be shrug

lethal wind
acoustic oxide
# lethal wind Why do you call it a lot? fetching all members once should suffice, you‘d get me...

Well, 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...)

lethal wind
lethal wind
acoustic oxide
#

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

#

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

limpid spoke
#

Right so

#

guildMemberRemove requires GuildMembers

#

But to fire on uncached members you would also need to enable the GuildMember partial

acoustic oxide
#

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

outer halo
#

yeah well, SO isnt' the best place for this

#

it's hard to tell what version the question/answer is for

#

and while the top answer in what you linked there isn't incorrect, it doesn't explain in literally any way why it's answered this way

#

the core issue is that your member was uncached, therefore wasn't emitted

#

the answer fixes that by supposedly caching everyone in some way, while you can just opt in into emitting anyway

acoustic oxide
#

Ic - thank you for the detailed explanation