Some of the logs were only useful for debug scenarios, so they have
been downgraded to DEBUG. Others were in INFO but supposed to be in
WARNING so those were upgraded.
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 to speed up cases where someone is just querying the length
of the underlying sequence. If anything else is done to the sequence
then it is copied from the original iterator.
This change should be mostly transparent.
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]>
Rapptz
mirnovov
z03h
Soheab
James Hilton-Balfe
Puncher
Josh
Bryan Forbes
Mikey
Maya
Alex Nørgaard
Soheab
Vioshim
Stocker
Sebastian Law
ow0x
Lilly Rose Berner
GoogleGenius