ShardingManager Woes
So my main project is still growing and I'm by no means at a point where sharding is required, but I'm also not one to put off something that I know will be a headache later on.
With that in mind I have implemented a sharding setup in my application now following the official guide. My application works and starts and given the lower guild count, only one shard gets spawned (shard 0). I've done this following many comments from people advising there is no harm in having it setup now to save me work later on.
My issue comes from the fact that no matter what I do, the
shard
property on client is always null even though I know the client was started within a shard.
This means I'm unable to use any of the shard utilities like broadcastEval
and fetchClientValues
for instance.
I've asked for general help regarding this in #djs-help-v14 but I'm hoping with it's own thread here, someone might have more insight on what I could be doing wrong.
Disclosure: I'm using DJS Dev at the moment, but I've been having this same behaviour with 14.7.1 and also now 14.8.0 as well.
DJS: [email protected]
Node: 19.3.05 Replies
Unknown User•2y ago
Message Not Public
Sign In & Join Server To View
ExtendedShardingManager
is simply the normal ShardingManager but with my custom logger added to it
and fastifyInit is just my fastify stuff being started. need to start it with shard manager otherwise it tries to start multiple times with the clients
sure
eventLogger is a winston instance
only imports logger does are the things it needs for itself:
understood. I added the execArgv because I needed to be able to test it was working locally in my dev instance before committing it live. on production, CLIENT_FILE
is a file named bot.js, on dev it's uncompiled bot.ts
an overview would be:
main process; sharding manager, fastify, winston
child process: djs client, prisma this should be fun
too big for discord, one sec
https://sourceb.in/4YkyMPL6RK
just to be clear, everything else works as intended. the client starts, all commands etc work. its literally just shard thats always null
yeah of course, uno momento
https://sourceb.in/eSa33PWj1R
thats exactly what I thought too but it's really confusing me
mhm
doesn't even have a token prop when I console log it
https://sourceb.in/udYf9y6pBe
but it shows shardCount
and the shards
array, and shard is still null 🙃
is it possible I'm just being denied shard usage because the application is in too few guilds?
I don'tPlease add the following code to your code base outside of any other event listeners and provide the full log output relevant to your issue.
• Note: if you initialize your Client as
bot
or other identifiers you need to use these instead of client
• If the output is too long to post consider using a bin instead: gist | paste.gg | sourceb.in | hastebinoh ok, one second
I did debug too, so here's that first of all for the application start
warn never gets fired for anything
...
I don't know how or why client would be starting twice
the start method you've seen in my ExtendedClient class above
also, removed the debug event because I was checking just warn
um, did that. but I'm doing it before the start method runs so its mostly null/useless
https://sourceb.in/nkUFTakLV1
I do note the very first line though about "Multiple clients created"
nope haha
wait
what do you mean
ohhh
I cheated and eval'd it. sorry, I'll log it in the code
of course, I thought it'd be easier. my apologies
so just to see what could be happening, I decided to log this.shard inside the start method, as the last thing and it fires once immediately as null, then my fastify loads and sharding manager spawns the shards and then it fires again but with the expected data
so you're right, multiple clients are starting but I don't understand how or why
my code isn't elegant but I'm following the same logic the guide does, letting the sharding manager be the one to load the client I'll come back with the results soon
omg. I actually worked it out. even though it's a gateway application, I use HTTP for interactions. I do this because I proxy them through my webhook server, so I can set the bot to maintenance mode if I want and users get a helpful response if the bot is offline, rather than red "Application did not respond" text.
I do this by listening for a forwarded HTTP request using fastify, and then forward the APIInteraction from discord to
client.actions.InteractionCreate.handle
. to do this, I was importing client from bot
and fastify was loading this with itself along with the shard manager. effectively spawning a client
actually a dumb problem to have haha. all my own doing as well
understood, thank you for being so patient with me on this too
any idea what would be the best way of making client available to this file without importing it the way I am here?
actually, don't worry. this is basic JS and I need to work it out on my own
entirely for user QoL. if the application is offline for whatever reason, you'll get met with an ugly red text saying it didn't respond. but with this, I can actually respond on my webhook server that forwards the interaction, stating that the application is offline
its low priority, I'll get rid of it for now
thats fair. in hindsight, I typically know if I've forced the bot offline so in those instances I'll just add the interactions endpoint URL in dev portal as needed