There were some dead-locking issues that I suspect were due to the
way the global rate limit was handled. This changes it into a simple
Event that allows multiple coroutines to pass through instead of one
by one.
If a 429 was already hit somehow then we're no longer pre-emptively
rate limiting and we're going to end up having a race condition in
the lock/unlock cycle.
Reactions can be be standard emojis, or custom server emojis.
Adds
- add/remove_reaction
- get_reaction_users
- Messages have new field reactions
- new events - message_reaction_add, message_reaction_remove
- new permission - add_reactions
This includes `Client.pin_message`, `Client.unpin_message` and
`Client.pins_from`. This also adds the `Message.pinned` attribute
to the `Message` object.
Logging in with an invalid token would throw a TypeError due to improper
passing of arguments to HTTPClient._token. Fix by properly passing the
keyword only bot argument.
This should have a more uniform approach to rate limit handling. Instead
of queueing every request, wait until we receive a 429 and then block
the requesting bucket until we're done being rate limited. This should
reduce the number of 429s done by the API significantly (about 66% avg).
This also consistently checks for 502 retries across all requests.
Rapptz
khazhyk
Hornwitser