RateLimit Questions

[sharp violet]

The image attached comes from the Rest Event Response. This message was received over 20 times within 2 minutes. I have a few questions about this.

1. Why is a rate limit message being sent when there are still 3 requests remaining?
2. Why was there no warning message from the Rest Event RateLimited?
3. Is there anything I can improve (since it is a shared scope), or how should I best deal with this?
4. The difference between shared scope and user scope is that with shared, all bots on the server are included and affected, and with user, only my bot is affected, correct?

I am not using the rejectOnRateLimit function.

[heady jackal]

What's the use case that's being rate limited. Cuz ideally you just wouldn't be rate limited. Like instead of fetching messages one by one you can bulk fetch messages

[sharp violet]

None of my questions above concern fetching messages. This can also be seen in the image, which refers to PATCH (edit).

[heady jackal]

Oh I'm sorry that's my bad. I misread the image. How frequently are you trying to edit the message?

[jade mantle]

Is this actually a ratelimit from the API itself or is it from cloudflare? I'm not really sure how/why you use the response event here. Does the call to message#edit reject or does it hang?

[sharp violet]

I thought I could simply integrate my rate limit log into the response event, as this would give me a central location for it. That's why I'm using the Rest Response Event. I don't have the exact result that I get back from message.edit at this moment.

[jade mantle]

For questions 1, 3 and 4 you'd be better off asking on ddevs #useful-servers

[sharp violet]

👍

[jade mantle]

Why do you use the response event at all is what I'm wondering. That's some serious overhead because the response needs to be cloned every time for that

[sharp violet]

Someone recommended it to me once, saying that I could use it and simply add a check to see if the status code is 429 and add my webhook log there.

[jade mantle]

You're missing the 'Retry-After' header in your logging, which would indicate a sublimit hit. Which I assume this is

djs does wait those out internally before retrying the request. But the response event emits before that, so your logs might give a different impression

Listening to the 'debug' event would probably be the better option for you

[sharp violet]

to the restDebug or client debug?

And besides, why would the log appear 20 times in a very short period of time? Shouldn't discord.js handle that?

How should I best set up my rate limit handling? I use the Rest Event RateLimited for warnings. But if you think I shouldn't use Response for this, how am I supposed to know when I've reached a rate limit somewhere?

Also, the Debug event only returns a string, which makes it difficult to create a webhook message with the information. In addition, I think this debug will be executed very often.

[jade mantle]

Well, sublimits aren't for the full route, so each sublimit is independent

And rest debug is what you'd want

[jade mantle]

Response event happens way more often than debug does. What's the use case for having this webhook inform you of ratelimits that get handled by djs? Or rather would be handled correctly if you didn't have several independent rest instances running. You might be interested in using @discordjs/proxy for those to have a central responsibility for ratelimit accounting

[sharp violet]

Webhook logging is built in, as the status bot listens for new messages in the channel with onMessage, extracts the information, and notifies the developers if it is important.