This should prevent ratelimit information from being cleared too early.
In order to prevent the dictionary from growing to large expired keys
are deleted once they've been deleted.
At present I'm unsure if this change would cause too much CPU pressure.
This is useful for cases where a rate limit is known to be
extraordinarily high, but you still want to handle the error.
This is common with routes such as emoji creation.
This should increase throughput of the number of requests that can be
made at once, while simultaneously following the new standard practice
of using the rate limit bucket header.
This is an accumulation of a lot of months of work between a few people
and it has been tested extensively. From the testing it seems to work
fine, but I'm not sure if it's the best way to do it.
This changeset does not currently take into consideration sub
rate limits yet, but the foundation is there via Route.metadata. In the
future, this metadata will be filled in with the known sub rate limit
implementation to allow them to have separate keys in the rate limit
mapping.
Co-authored-by: Josh <[email protected]>
Segments where readability was hampered were fixed by appropriate
format skipping directives. New code should hopefully be black
compatible. The moment they remove the -S option is probably the moment
I stop using black though.
This reduces some repetition in many functions and is ripped out of
the webhook code. This also removes the unused HTTP functions for
interaction responses since those belong in the webhook code rather
than the HTTPClient.