REST rate-limit event

[InnateAlpaca]

Hello, REST is useful for making calls to the discord rest API, as it will handle the rate limits, retries, bucket changes, etc.

The problem with it is that it won't provide information to the developer about the current status of the buckets, the actual rate limits. As a consequence it's impossible to nicely manage rate limits beforehand.

Example: Editing a message.
Suppose we are editing a message every few ms, let's say we are updating the current weather condition, the temperature. Now, as we are doing this too often and for too many users we get rate limited. Our request get cached by discordjs and made after the timeout has passed (retry-after). Thing is that now we would have new data, instead discordjs is sending outdated data (that had been queued on rate limit hit) potentially hitting the rate limit again and again, while always pushing outdated data.
This could be avoided by knowing beforehand how many calls we can make to that bucket instead of queuing them.

The information about rate-limits is present in the response headers, but REST is stripping it away, so no event actually exposes them. And rate-limited, is only for when you already hit the limit.
I would suggest to add a rate-limit event fired at every request with the rate-limit information provided in the headers, so that developers can properly handle a queue before performing requests with REST. In the example above we would make sure to make only the allowed number of requests to an endpoint before limit-reset.

[vakiliner]

Did you mean rejectOnRateLimit?

discord.js/packages/rest/src/lib/utils/types.ts

Line 109 in eaa6863

rejectOnRateLimit: RateLimitQueueFilter | string[] | null;

[InnateAlpaca]

No? According to docs that's "A function that determines whether the rate limit hit should throw an Error". I'm talking of having information about the rate limits before hitting the limit.
If you do a manual request you'll get headers such as

• x-ratelimit-remaining
• x-ratelimit-limit
• x-ratelimit-reset-after
  These are present in the responses of any request to the API. If you know how many requests you've got left, and when is the limit resetting you can prevent 429 and queuing stale data. Avoid queuing more requests and send fresh data as soon as the rate limit is reset.

[didinele]

We very deliberately abatract this away from you. You can indeed accomplish what you want by using rejectOnRateLimit. With your example in fact, simply wrapping your message edit call with a try..catch block, where errors other than Ratelimit are discarded accomplishes exactly what you desire.

Even beyond that basic example, you can accomplish just about every reasonable usecase I can think about. For the record, your use case is not actually reasonable, it's API abuse, I entertained it for the sake of example.

p.s., perhaps the docs aren't very clear, but rejectOnRateLimit fires even without you truly hitting it, we stop the request from going though so you don't 429.

[InnateAlpaca]

Alright, after digging a little bit more yes, most of the information I could need is in the errors thrown, if enabled.