@discordjs/brokers timeout when not using reply()
I'm using the
@discordjs/brokers package. Specifically the Redis streams broker.
In emitted events you get these ack and reply functions. I am aware of ack and it's need, however reply doesn't seem useful to me. I guess it could be used to inform the publisher that the event was received, but I'd prefer to not send 2 calls over redis for every event (publish and reply).
However, when I just simply don't use the reply() function, I get a timeout 5 seconds later from the caller, which apparently is expecting a reply39 Replies
- What's your exact discord.js
npm list discord.js and node node -v version?
- Not a discord.js issue? Check out #other-js-ts.
- Consider reading #how-to-get-help to improve your question!
- Explain what exactly your issue is.
- Post the full error stack trace, not just the top part!
- Show your code!
- Issue solved? Press the button!
- ✅ Marked as resolved by staffyou're using the wrong type of broker
there's a pub/sub one and RPC with replies
use the former
Id prefer to use streams though
don't know what you mean
both are stream based
they're the same internally, they just handle packets a little different
one takes responses one doesn't
The pubsub broker isn't based on redis pub sub?
nope
Ah
That's a confusing name then haha
I'll look into the pubsub one then, ty!
well
no matter the underlying stack (redis/rabbitmq/whatever)
they follow that pubsub/rpc naming conn.
Might be worth mentioning somewhere that pubsub broker isn't redis pubsub
the class' names reflect the data pattern
not the stream method used
yeah i guess
Yeah that makes sense, it's just that redis naming kinda conflicts
yeah fair
lmk if this stuff works, its not really tested
i used it a bit and it seemed ok
With using replies it seemed to work really nicely
Just changed it around, works as expected! Really happy with these new djs packages so far
i cant test it on scale yet but i assume it shouldnt really change anything, as thats mainly just dependent on redis
yup! that was my sentiment too
glad this helped someone, i haven't seen anyone else use it here other than me ^^
well this isnt fully related to this post, but do you happen to know whats going on here? Am i doing something wrong or is this a bug
Directly from the example, but the types dont match up
Typescript only shows this, and only the top 2 work, not sure whats going on with the `"[unknown]" one
@DD ^ if you know :) seeing as you said youre the only one using these packages haha
const client = new Client({ rest, gateway });
yeah
ahh this was the issue
i had it imported from discord-api-types
do you know if i should be expiring my session data? A few times after starting my test bot after it being off for a while, i got a spam of just shards being closed. Resetting the cache fixed it, but im not sure how to tackle this. Right now i have it set to expire but its causing unnecessary reidentifies.
I haven't really debugged it as its very sporadic, but my assumption is that the cached session isnt valid anymore, but it seems /ws doesnt reidentify when the cached data is invalid, and instead just keeps retryingyeah, this
ahh thank you very much, feel stupid now
Also, is there a possibility for a rabbitmq broker to be added to this package? I would be interested in maybe working on a pr to add it if needed
it'd be welcome
we'd mainly have to look into a way to make sure its not a direct dependency
so non-users dont have it added to their tree
in other words, make it a dev dep and have the interface take an AMQP client as a parameter
ahh okay, makes sense i think
oh btw im struggling a bit with these custom events in the ws manager. I figured out you can get the manager to emit events that you send it from the worker process, but listening to these makes typescript complain
and i cant figure out a way to satisfy typescript
i mean, i can just ts-expect-error it, which works fine, but itd be nice if there was some way to make these custom events typesafe as well
oh no no no no
please don't do that
the worker channel is for internal use
if you want to do something else with it, be my guest but don't leverage the existing opcodes/payload structure we have going there
its a totally unintended side effect that an arbitrary string like "someEvent" behaves as you'd expect
and I'll never guarantee it'll keep working
ahh interesting..
its hard to do anything else with it though, as the worker is internal and i cant seem to access it
i need to send some data from the gateway workers to the parent thread
but i cant add event listeners on the worker afaik
can you be more specific about your use case
I collect metrics (events received), i collect these on the workers as i want to see the amount of events received for each worker and also each shard. But to expose the metrics, i need to collect them all together
meaning i send the metrics to the main thread, merge them into a prom-client registry, then expose that
along with some other metrics
are you sure you need to collect them in the main thread :meguFace:
either way, this should be do-able without messing with internals, let me think for a sec
well, i dont want to setup a separate api on each worker
is this like
prometheus?
fair enough
yea
these are the metrics i want to collect from the gateway
okay, so
there's def. a way to accomplish this using a custom MessageChannel in your worker script
but it's relatively tricky
i'll pr a feature for sending custom data like this
Ah ty! thatd be nice, just by looking through the source code, what i was doing seemed almost intended haha
sending an Event opcode which then emits an event based on the payload
can I ask how big your bot is btw
50k, but for now just testing with my test bot in 6 servers lol
oh good, I don't even have to bs through it
@souji mind adding them to #big-apps? they're using my fancy pants stuff :Poi3: thanks
:)
im just slowlyy working towards improving my bot as its a huge mess right now
can stop using this thread now, it grew out of scope anyway
:CATTHUMBSUP: