MESSAGE_REACTION_ADD emoji.animated is unreliable

[MattIPv4]

I'm currently experiencing a very weird issue where the animated property of the emoji data in the MESSAGE_REACTION_ADD appears to be unreliable.

From my testing, it appears that if the message already has a reaction from a bot, an additional reaction of the same emoji added to the message will return animated=false in the payload when the emoji is still animated.

https://drive.google.com/file/d/1kwY2hA_rpvbaHEaIbPqZgYR2DBsqtBTR/view?usp=sharing

Whilst I can see in the documentation that the value is marked as optional, it appears in this situation that it is being sent as false, otherwise I would expect the value to be None based on the code that the value runs through in the library.

Looking through the discord.py code, which I'm using to test, it appears that the value is never forced into a boolean and so from what I can tell, this value is the raw one being presented from Discord.

https://github.com/Rapptz/discord.py/blob/rewrite/discord/gateway.py#L396-L403
https://github.com/Rapptz/discord.py/blob/rewrite/discord/state.py#L400-L405
https://github.com/Rapptz/discord.py/blob/rewrite/discord/emoji.py#L32-L98

Note: It might be worth mentioning that the animated emoji in question is located on a different server from where these reactions are happening but both myself and the bot are also in this server.

[z64]

I had some time, so I set up a script to dump raw JSON payloads from the gateway and double check this report with data apart from any library implementation.

First creating a reaction with my user account:

{
  "user_id": "120571255635181568",
  "message_id": "535084846297513984",
  "emoji": {
    "name": "blobseizure",
    "id": "425223977305374720",
    "animated": true
  },
  "channel_id": "246283902652645376",
  "guild_id": "225375815087554563"
}

Followed by creating a reaction with my bot account:

{
  "user_id": "295427578980990976",
  "message_id": "535084846297513984",
  "emoji": {
    "name": "blobseizure",
    "id": "425223977305374720",
    "animated": false
  },
  "channel_id": "246283902652645376",
  "guild_id": "225375815087554563"
}

Notes:

• The emoji in these examples belong to the guild where the reactions are taking place.
• Kind of obvious, but this is not specific to bots. I've tested that the first emoji will always be true, and the second will be false regardless whether the two users are bot accounts or not.
• This occurs per-reaction. A third, but different animated reaction will have animated as true again, etc.
• emoji.animated is still properly set to true on GET /channels/{cid}/messages/{mid}.

[MattIPv4]

@z64 Thank you, glad it's not just an issue I'm seeing :)

[krisppurg]

This has also been happening to MESSAGE_REACTION_REMOVE with the same issue.

{
    "user_id": "222794789567987712",
    "message_id": "539798280654159872",
    "emoji": {
        "name": "dancingdog",
        "id": "539795250315657216",
        "animated": false
    },
    "channel_id": "538302783280119811",
    "guild_id": "538300663260512276"
}

I also checked if that reaction emoji is animated or not, by getting the message using rest

"reactions": [
    {
        "count": 2,
        "me": true,
        "emoji": {
            "animated": true,
            "id": "539795250315657216",
            "name": "dancingdog"
        }
    }
]

[night]

To clarify and shed some light on this behavior, the source of all of these inconsistencies are due to us not loading the emoji record when we send these events. I am assuming we do this as an optimization to limit extra queries for data our client doesn't need. We only pull down the emoji record for the initial reaction, subsequent reactions + unreactions will not. Thus you cannot rely on emoji name/animated on any event other than the initial reaction. Emoji names can actually be spoofed on some events.

[MattIPv4]

@night Why just not send the field then instead of sending an actual incorrect value? The docs mark it as optional which is fine, but sending an actual incorrect value seems like a really odd way to treat the field as optional?

[mixno373]

Fix it pls

[GatewaySocket] <~ MESSAGE_REACTION_ADD
Object
...
emoji:
    animated: true
    id: "509792189585293316"
    name: "Tsumiki"
...

[GatewaySocket] <~ MESSAGE_REACTION_REMOVE
...
emoji:
    animated: false
    id: "509792189585293316"
    name: "Tsumiki"
...

In MESSAGE_REACTION_REMOVE animated is always FALSE

[night]

I've opened a PR to address these issues, but just FYI there will be a "breaking" change in the sense that the documentation will be updated to reflect a condition that is already true in production today.

Only MESSAGE_REACTION_ADD may have animated and on MESSAGE_REACTION_REMOVE it is possible to receive null for name (specifically when a user is banned this always happens to their reactions prior to these incoming changes). On individual removes, name will no longer be able to be spoofed and name may be null if the emoji record is not found.

Visually, here are the message reaction emoji records you can expect to see:

{
   "id": null,
   "name": "💯"
}

{
  "id": 347239456284572957,
  "name": "customemote",
  "animated": true
}

{
  "id": 347239456284572957,
  "name": null
}

[night]

these fixes will be included in the next api deploy