Activity's "application_id" field is 1 (integer)

[myrkvi]

Description

During the GUILD_CREATE and PRESENCE_UPDATE gateway events, there is a user who has an activity with the name Silksong, that has the field application_id set to 1. This does not seem to be a valid snowflake ID, per the documentation.

Excerpt of JSON received is:

      {
        "user": {
          "id": "<redacted>"
        },
        "status": "dnd",
        "client_status": {
          "desktop": "dnd"
        },
        "broadcast": null,
        "activities": [
          {
            "type": 4,
            "state": "spong",
            "name": "Custom Status",
            "id": "custom",
            "emoji": {
              "name": "🧽"
            },
            "created_at": 1727805739426
          },
          {
            "type": 0,
            "timestamps": {
              "start": 1727654717203
            },
            "session_id": "a1b20f01567a8cc7c1021ee9dc40ec43",
            "name": "Silksong",
            "id": "e1b1ccad28c06a04",
            "flags": 1,
            "details": "Hollow Knight: Silksong",
            "created_at": 1727654737119,
            "assets": {
              "large_image": "mp:attachments/1276169578115760149/1290101508859498548/Hornet_banner_wide-1.png?ex=66fb3c28&is=66f9eaa8&hm=fcd0a215d68519c40dbe12fe6f02c2efa4be365d29f23c0f481323a504193ce2&"
            },
            "application_id": 1
          }

Steps to Reproduce

I do not know if there is a way to reliably replicate this. This seems to happen in a medium-sized guild (~5000 users) , but no others. Would likely require someone to play Hollow Knight: Silksong, as that is the game indicated.

Expected Behavior

The application_id field should be a valid snowflake / JSON string

Current Behavior

the field application_id is the integer 1.

Screenshots/Videos

No response

Client and System Information

Library: disgo v0.18.13 OS: Heroku-based Ubuntu Linux and Arch Linux

[Cynosphere]

This is technically a partial non-issue because all it breaks is fetching the application, whether that be a client opening the profile or bots going through presences.

This presence comes from internally dispatching a presence through the client via client mods, as also evident by the fact the large_image key points to an attachment, whereas the RPC will always convert links passed through to the external route of media proxy.

Clientside validation is done, but only for presences over RPC. Once it's gets to being dispatched, no validation is done. Discord could add further serverside validation if they wanted to prevent this, but it breaks very little as I mentioned.

[myrkvi]

This breaks clients with strict typing, when deserializing JSON.

[advaith1]

per presence update docs:

no fields are required, and the types of the fields are not validated. Your client should expect any combination of fields and types within this event.

since snowflakes are internally stored and processed as numbers, and only converted to strings during serialization if they are over the max int, there are unfortunately various cases where small number snowflakes are serialized as numbers instead as strings.