The library had a memory leak in the case using the global emoji cache.
When the bot would leave the guild, the Emoji would maintain a strong
reference to the Guild keeping them alive along with the entire state
associated with it.
Hopefully this means when the bot has some lingering object for
whatever reason, the memory doesn't double due to it having a strong
reference to an outdated connection state.
Sometimes the bot would keep waiting for chunks that somehow finished
before getting to the `wait` call. This is more so a temporary fix
rather than a fully correct one.
Discord can sometimes send integer 0 as the emoji id instead of
null to signify a non-custom emoji, which was causing a crash due
to a 'is not None' check assuming the reaction was for an emoji
with id 0. Probably a discord bug, but preferable to handle here
rather than crash users.
This changes the event signature to be (reaction, user) instead of
(message, reaction, user) since the reaction data class already has
the message being reacted to as a member.
The name was shortened from on_message_reaction_ to on_reaction_ since
the message prefix was deemed redundant.
Reaction objects with custom Emoji are partial. If we know of this Emoji
(can find it on this client) then inject it. Otherwise, leave it as a
hollow Emoji. We can still react with a hollow Emoji, but can't get other
metadata about it.
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