Sychro problem

I'd like to know a little more about automatic rate limit management with Discord.js For example, if I make a function call to attempt to kick a guild member, and it throws due to a rate limit, I'd like this kick attempt NOT to be automatically re-executed after the retry after specified by Discord. I need to know when the kick has failed or not, so that I know whether to record it in a DB history or not. If it retries itself by "Magic", I'll end up having desynchro' between the history and the kicks performed. So I'd like to know how this automatic "retry" of Discord.js works. Does the simple fact of catching the exception raised by the kick command myself disable this auto retry? How does it work?
10 Replies
d.js toolkit
d.js toolkit2mo ago
- 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 staff
duck
duck2mo ago
if the request is being retried, it shouldn't be throwing an error however you can specify the rejectOnRateLimit REST option so that it does reject instead of retrying
d.js docs
d.js docs2mo ago
:propertysignature: ClientOptions#rest @14.15.3 Options for the REST manager :propertysignature: RESTOptions#rejectOnRateLimit @2.3.0 Determines how rate limiting and pre-emptive throttling should be handled. When an array of strings, each element is treated as a prefix for the request route (e.g. /channels to match any route starting with /channels such as /channels/:id/messages) for which to throw RateLimitErrors. All other request routes will be queued normally
athene___
athene___2mo ago
Do you have a direct link to that ? I've ctrl+f and didn't found
duck
duck2mo ago
this has a link, yes
athene___
athene___2mo ago
I can't understand wher to place it
duck
duck2mo ago
in your Client options, you can specify rest: { rejectOnRateLimit: ... }
athene___
athene___2mo ago
if the request is being retried, it shouldn't be throwing an error
So, awaiting the request could take a relatively "Long" time, but will keep a predictable behavior in my execution flow?
duck
duck2mo ago
if you're allowing it to be requeued instead of rejecting, yes
athene___
athene___2mo ago
Awesome, thank you a lot!