This change was made since Discord doesn't support IPv6, and there were
concerns about clients with DNS64 enabled without NAT64.
However, this breaks hosts who don't have v4 connectivity and are
_actually_ running NAT64.
Having DNS64 without NAT64 is really an issue on the client's end. It
would break far more than just discord.py, so I don't think we should be
concerned about those cases.
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]>
DA344
Ginger
Michael H
Rapptz
Sherlock
owocado
MCausc78
Lilly Rose Berner
Andrin
Soheab
Deep Jain
Oliver Ni
Lucas Hardt
Mikey
Lucas Hardt
Josh
Ionite