The library logs when a ratelimit is reached using the logging library, but the logging level must be set to DEBUG.
The logging level for this message should be WARNING. Exhausting ratelimits should be avoided as far as one can. The bot's workflow can potentially hang at one place for quite a significant period of time. Thus, this should have a higher level compared to other noise of DEBUG.
The logging level for the message is DEBUG.
Ratelimit exhaustion messages should be logged with WARNING level, not DEBUG.
Hitting ratelimits is extremely common. I'd rather not clog my WARNING level logs with extra junk.
Not really, if you hit the ratelimits too frequently, you should probably look into refactoring.
WARNING is the level for actual rate limit hits. DEBUG is for the pre-emptive rate limits, i.e. the library is waiting for the rate limit to be over before it hit it.
If the library throttles requests with preemptive rate limits, then hitting actual rate limits is a cause for concern and should be ERROR, as the library failed to throttle the requests and the bot risks ban by the API, breaking the bot.
Atleast instances of high ratelimits should be logged as WARN.
There is no error here.
Due to how Discord rate limits are implemented (there are sub rate limits, shared routes, multi-process requests) a 429 is something that just happens every so often and should just be a warning, not logged as an error. There is no error associated with it.
Understandable.
On my part, I intended to refer to high pre-emptive ratelimits, of the order of hours or so, not of things like message send ratelimits which gets encountered often.