Rate limit headers are incorrect

[KubaZ2]

Description

Headers indicating rate limits in responses are only valid when you are ratelimited. headers when not rate limited:

x-ratelimit-bucket: d1240eeffb4c549bd62b579ece0ffd01
x-ratelimit-limit: 50000
x-ratelimit-remaining: 48773
x-ratelimit-reset: 1668720787.644
x-ratelimit-reset-after: 102737.719

headers when rate limited:

x-ratelimit-bucket: 1d3c67957bcdccc6709861c232df8529
x-ratelimit-limit: 5
x-ratelimit-remaining: 0
x-ratelimit-reset: 1668618055.755
x-ratelimit-reset-after: 5.588

Steps to Reproduce

for i in {0..6}; do curl 'https://discord.com/api/v10/channels/{channel.id}/messages' -H 'Authorization: Bot $token' -H 'Content-Type: application/json' --data-raw '{"content": "wzium"}' -v; done

Expected Behavior

Rate limit headers are always correct

Current Behavior

Rate limit headers are incorrect when you are not rate limited

Screenshots/Videos

No response

Client and System Information

No response

[jgoldshlag]

We are also running into this, but I think with slightly different symptoms:

Starting about 20 hours ago, our bot started reporting issues with rate limits. After drilling into the rate limit headers, it looks like there is some new rate limit of 50,000 that is getting reported for a rate limit for all interactions made in any channel. The rate limit seems to have a 72 hour reset time.

There is also a similar rate limit for DM'd interactions with a bot, though it seems to be a different pool of limits, but with the same 50K/72h limits

[lytefast]

There is an ongoing effort to migrate RLs from bucket style to leaky bucket style. However nothing in the last 24H has been enabled besides gateway session starts. There was a refactor to the RL parameters though, which I think surfaced this issue.

In regards to the OP. The RL buckets are different, which leads me to believe that you are hitting a different RL. The first RL d1240eeffb4c549bd62b579ece0ffd01 is an internal RL for stopping indexing on a channel with bot spam; which should not be exposed. The 2nd RL 1d3c67957bcdccc6709861c232df8529 that you are hitting is our bot_user:channel:send RL. The RLs are behaving the same as previously AFAICT.

I believe I found the bug in the refactor. Basically we shouldn't have even exposed the first RL.

[lytefast]

Fix is deploying now.