Suggestion for an endpoint to show source ratelimits

[Tomato6966]

I wanna suggest a new rest endpoint
/ratelimits

-> It returns ratelimit status of all sources if available

e.g. you're ratelimited for youtube, soundcloud and plugin:lavasrc:deezer -> it returns a list (array) of information when it happened, if available est, and what source it's on

I do such things manually client sided, to block user actions of a source if a source is ratelimited.
Could be nice to do something similar with lavalink (just informations)

[Drapersniper]

Let's not and let's just handle things like this on client - as different clients may decide to have different ways to handle ratelimits and bans.

lavalink should only provide the ability to search and play content nothing else natively.

[Tomato6966]

Yes but lavalink logs error on ratelimits
why not allow users to do a GET /ratelimits to see which source hit a ratelimit in the past / are ratelimited

[Drapersniper]

I'll admit it - I misread it originally due to " to block user actions of a source if a source is ratelimited-Could be nice to do something similar with lavalink".

While exposing the info may be nice, it probably wont be as simple as "Lets expose this info" this would require Lavalink to keep track of all 429 and other errors related to ratelimiting/bans, not to mention how it would integrate with ip rotation for youtube.

What you are proposing is "Store the time it errors and what source, then make it available in a new end point", "Automatically remove the stored data when the next request is successful" ?

How would a client know something is not available again if this scenario, as it will remain in the list until a successful request? if this is not the scenario you are suggesting what are you suggesting?

[Tomato6966]

Here couple examples:

If Ip rotation fails -> 429 spams -> such things can be listed in /ratelimits

If no ip rotation -> 429 -> such thing can be listed in /ratelimits

If Ip rotation works, but each ip address is ratelimited -> such things can be listed in /ratelimits

If server isn't responding (e.g. soundcloud down) -> can be listed in /ratelimits

(in the end the client can decide, when to do requests again)

Once a source "works" again -> /ratelimits gets cleared of that source again

[freyacodes]

Almost all of these errors you describe can be returned to the client either in the form of 5xx http responses or WebSocket events

Then one could argue whether we need better classification of errors, which I personally don't see the need for right now

Once a source "works" again -> /ratelimits gets cleared of that source again

That usually requires accessing the service again