`DELETE /invites/:code` has no ratelimit headers

[didinele]

Description

Calling the DELETE HTTP method on /invites/:code provides no ratelimit headers in the response, eventually leading to rate limits for bots that often call this route, i.e. a @discordjs/rest/discord.js v14 bot's debug log:

Global  : false
Method  : delete
Path    : /invites/[redacted]
Route   : /invites/[redacted]
Limit   : Infinity
Timeout : 500ms
Sublimit: 5000ms

Note how we have no relevant information e.g. the Limit (which would come from x-ratelimit-limit), but just the timeout and Global: false which is returned in the JSON payload from the 429.

Steps to Reproduce

curl -i -H "Authorization: Bot $DISCORD_TOKEN" -X DELETE https://discord.com/api/v10/invites/[somecode] - assuming DISCORD_TOKEN is a variable in your shell, and [somecode] is a valid invite code your bot can manage.

Expected Behavior

The response includes x-ratelimit-[whatever] headers.

Current Behavior

The response does not include any ratelimit headers:

➜ curl -i -H "Authorization: Bot $DISCORD_TOKEN" -X DELETE https://discord.com/api/v10/invites/Dt2pu7Y4
HTTP/2 200
date: Tue, 05 Jul 2022 18:53:09 GMT
content-type: application/json
set-cookie: __dcfduid=b65de186fc9311ec84e7224b5a8897c3; Expires=Sun, 04-Jul-2027 18:53:09 GMT; Max-Age=157680000; Secure; HttpOnly; Path=/
set-cookie: __sdcfduid=b65de186fc9311ec84e7224b5a8897c35751bc9a73c56b972b53a3ebbf638df4168d72ece52650c4c8863a7b79b621f2; Expires=Sun, 04-Jul-2027 18:53:09 GMT; Max-Age=157680000; Secure; HttpOnly; Path=/
strict-transport-security: max-age=31536000; includeSubDomains; preload
x-envoy-upstream-service-time: 116
via: 1.1 google
alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400
cf-cache-status: DYNAMIC
expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct"
report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=hgYDFDyan%2Fig0bgtlwz0q9PCjPzzG2l0Ze0YMxkRGag2r12%2B5QPDSLIDnpxJSGG%2FGFdW%2FmLUBW7d4kRtdRWp2Logzuf50UvLCi2hg8jdoVWIGSJ5qkEvOScFK42B"}],"group":"cf-nel","max_age":604800}
nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800}
x-content-type-options: nosniff
server: cloudflare
cf-ray: 72624d432c395cb0-FRA

[redacted JSON payload]

Screenshots/Videos

No response

Client and System Information

➜ curl --version
curl 7.68.0 (x86_64-pc-linux-gnu) libcurl/7.68.0 OpenSSL/1.1.1f zlib/1.2.11 brotli/1.0.7 libidn2/2.2.0 libpsl/0.21.0 (+libidn2/2.2.0) libssh/0.9.3/openssl/zlib nghttp2/1.40.0 librtmp/2.3
Release-Date: 2020-01-08

[Zoddo]

Not all routes have rate-limits. You are only bound to your global rate-limit if they don't. Looks like this route has indeed a rate-limit, but the headers aren't exposed.

[didinele]

Point was that we are indeed hitting 429s on this. Just edited in something to address that.

[Mehgugs]

What is the ratelimit scope? – If this is missing then it's a bug.

[switchupcb]

There are three potential cases:

1. It has a rate limit bucket that isn't being showcased.
2. You hit a global rate limit, which should showcase a Retry-After header (of around 1 second).
3. You were Cloudflare banned, which should showcase a Retry-After header (of around 50 minutes).

Rate limit scope isn't required for this to be a bug, but a missing Retry-After header would be.

Related: https://github.com/discord/discord-api-docs/issues/5144

[devsnek]

This is indeed a bug, a fix should be rolled out soonish.

[Zoddo]

Edit: Posted as the same time than devsnek who said it's a bug, so I may be totally wrong here :upside_down_face:

Here is what I understand regarding this endpoint and returned headers:

• There isn't any classic (user) ratelimit on this endpoint, because there isn't any major parameter (guild or channel id) that can be used. This explains why there is not any X-Ratelimit-* headers returned on success responses.
• However, there is a shared rate limit (likely per guild or per channel) on deleting invites. You only get a X-RateLimit-Scope: shared and Retry-After headers when exceeding it.
  • The docs aren't really clear about this, but when encountering a shared ratelimit, only these 2 headers are guaranteed. Other headers, if sent, always represent your user ratelimit. To better understand, you can see this (at first look weird) example when exceeding a shared ratelimit:
    • X-RateLimit-Remaining is not equal to 0 as you may expect
    • X-RateLimit-Reset-After (which is about your user ratelimit) is not equal to Retry-After (which is about the shared ratelimit you hit).
  • The docs may need some clarifications that X-RateLimit-{Limit,Remaining,Reset,Reset-After,Bucket} always represents the user's ratelimit state (even if you are encountering another ratelimit type)

[devsnek]

fix should be out very soon

[switchupcb]

@devsnek What was the fix?