You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The response returns a rate limit bucket with a 2000 request limit, then swaps to the rate limit bucket with an accurate rate limit of 30 requests per period.
You can prove that this second rate limit bucket is the accurate rate limit for this request (i.e. Get User) because there are tests — which have handled this limit for multiple years correctly — which queue over 30 Get User requests to test the handling of Discord Route Rate Limits.
Steps to Reproduce
This test has not changed in two years with the exception of increased request timeouts, which represents the amount of time a request waits for a response.
Here is the human readable steps to reproduce this issue.
Send a Get User request.
Use rate limit headers to send more Get User requests according to the specified rate limit.
Receive an HTTP 429 response before the bot has exhausted the rate limit specified during steps 1 and 2.
Expected Behavior
The rate limits headers are accurate.
Current Behavior
Here is the current behavior which shows
the request prior to the 429 HTTP response with headers X-Ratelimit-Bucket: 06f50622af95a11ccfb8304b866ed5b0\r\nX-Ratelimit-Limit: 2000\r\nX-Ratelimit-Remaining: 1980.
the request with a 429 HTTP response with headers X-Ratelimit-Bucket: 481e0bf1883da82f2e83411bc2da9c89\r\nX-Ratelimit-Limit: 30\r\nX-Ratelimit-Remaining: 0.
I want to confirm this, running into exactly the same issue (except that it's in JS).
Original Post on Discord:
I am writing a discord API library and currently reworking my rate-limit setup. For testing, I ran
while(true){awaitbot.request();}
For some reason, the reported rate-limit buckets are wrong. I print the current bucket for each request and how many more requests are remaining in there.
If I get rate-limited, then I print some more information.
Weird things:
The "remaining" value never changes and stays pretty high (1999), which I could explain, because the "reset-after" for this bucket is very low (~0.3 seconds)
Once I've hit somewhere around 35 requests, the bucket ID suddenly changes to another and reports "remaning == 0"
The 429 response contains the header "retry-after" and a field in the JSON body "retry_after", which have two completely different values!
Once I wait the amount of time, specified in the "retry-after" header, the bucket ID switches back to the old one
Description
https://discord.com/api/v10/users/
returns inaccurate rate limit headers.The response returns a rate limit bucket with a 2000 request limit, then swaps to the rate limit bucket with an accurate rate limit of 30 requests per period.
You can prove that this second rate limit bucket is the accurate rate limit for this request (i.e.
Get User
) because there are tests — which have handled this limit for multiple years correctly — which queue over 30Get User
requests to test the handling of Discord Route Rate Limits.Steps to Reproduce
This test has not changed in two years with the exception of increased request timeouts, which represents the amount of time a request waits for a response.
Both result in the same behavior described.
Here is the human readable steps to reproduce this issue.
Get User
request.Get User
requests according to the specified rate limit.Expected Behavior
The rate limits headers are accurate.
Current Behavior
Here is the current behavior which shows
X-Ratelimit-Bucket: 06f50622af95a11ccfb8304b866ed5b0\r\nX-Ratelimit-Limit: 2000\r\nX-Ratelimit-Remaining: 1980
.X-Ratelimit-Bucket: 481e0bf1883da82f2e83411bc2da9c89\r\nX-Ratelimit-Limit: 30\r\nX-Ratelimit-Remaining: 0
.Screenshots/Videos
No response
Client and System Information
See test and current behavior.
The text was updated successfully, but these errors were encountered: