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
- 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 staffif 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: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 normallyDo you have a direct link to that ?
I've ctrl+f and didn't found
this has a link, yes
I can't understand wher to place it
in your
Client
options, you can specify rest: { rejectOnRateLimit: ... }
if the request is being retried, it shouldn't be throwing an errorSo, awaiting the request could take a relatively "Long" time, but will keep a predictable behavior in my execution flow?
if you're allowing it to be requeued instead of rejecting, yes
Awesome, thank you a lot!