ThreadMetadata#create_timestamp is sent as null in GUILD_CREATE#threads

[A5rocks]

Description

ThreadMetadata#create_timestamp is documented as optional, non-nullable in the docs. With REST, it apparantly follows this documentation. However for gateway, it is sent as null in GUILD_CREATE's threads attribute.

(Am I surprised that this happens? No. But I'm not making a PR because I am unsure if this is intentional.)

Steps to Reproduce

1. Have a guild with an active thread that was made before 1/9/2022.
2. Connect to the gateway.
3. Look at the GUILD_CREATE for that guild and its threads attribute. See "Current Behavior" for an example of this.

Expected Behavior

The docs don't lie to me.

Current Behavior

The docs lie to me.

Here's how Python's json module parsed GuildCreateEvent#theads:

[{'type': 11, 'thread_metadata': {'locked': False, 'invitable': True, 'create_timestamp': None, 'auto_archive_duration': 10080, 'archived': False, 'archive_timestamp': '2021-12-21T04:03:10.474000+00:00'}, 'rate_limit_per_user': 0, 'parent_id': 'xxxxxxx', 'owner_id': 'xxxxxxx', 'name': 'hug thread', 'message_count': 50, 'member_count': 13, 'last_message_id': 'xxxxxxx', 'id': 'xxxxxxx', 'guild_id': 'xxxxxxx'}, {'type': 11, 'thread_metadata': {'locked': False, 'create_timestamp': '2022-01-28T20:02:25.600000+00:00', 'auto_archive_duration': 1440, 'archived': False, 'archive_timestamp': '2022-01-30T09:24:15.003270+00:00'}, 'rate_limit_per_user': 0, 'parent_id': 'xxxxxxx', 'owner_id': 'xxxxxxx', 'name': '(^^)', 'message_count': 2, 'member_count': 1, 'last_message_id': 'xxxxxxx', 'id': 'xxxxxxx', 'guild_id': 'xxxxxxx'}]

Screenshots/Videos

No response

Client and System Information

My own library, but with everything skipped except json parsing.

[lukellmann]

Was not able to reproduce this, are you sure this is not an issue with the way you deserialize the event?
The JSON I got:

{
    "t": "GUILD_CREATE",
    "s": 2,
    "op": 0,
    "d": {
        ...
        "threads": [
            {
                "type": 11,
                "thread_metadata": {
                    "locked": false,
                    "auto_archive_duration": 1440,
                    "archived": false,
                    "archive_timestamp": "2022-01-31T18:15:50.738443+00:00"
                },
                ...
            },
            {
                "type": 11,
                "thread_metadata": {
                    "locked": false,
                    "create_timestamp": "2022-01-31T18:15:40.406000+00:00",
                    "auto_archive_duration": 4320,
                    "archived": false,
                    "archive_timestamp": "2022-01-31T18:15:40.406000+00:00"
                },
                ...
            }
        ],
        ...
    }
}

[Quahu]

The API is sending nulls.

[A5rocks]

Yes, I still recieve null in my threads parameter. Here's the trimmed (raw) json I got, thrown into a prettifier:

{
  "threads": [
    {
      "type": 11,
      "thread_metadata": {
        "locked": false,
        "invitable": true,
        "create_timestamp": null,
        "auto_archive_duration": 10080,
        "archived": false,
        "archive_timestamp": "2021-12-21T04:03:10.474000+00:00"
      },
      "rate_limit_per_user": 0,
      "parent_id": "xxxxxxx",
      "owner_id": "xxxxxxx",
      "name": "hug thread",
      "message_count": 50,
      "member_count": 14,
      "last_message_id": "xxxxxxx",
      "id": "xxxxxxx",
      "guild_id": "xxxxxxx"
    }
  ]
}

(You'll notice one of the threads disappeared since I just took this snapshot of the sent JSON now)

I'm pretty sure no steps of deserialization is messing up, as this is roughly what I did:

async for message in websocket:
  res = json.loads(message)  # python's json module
  if res['t'] == 'GUILD_CREATE' and res['d']['id'] == 'xxxxxxx':
    with open('guild.json', 'wb') as f:
      f.write(message.encode())

I then checked guild.json in my editor of choice.

[ajpalkovic]

Older threads won't have the create timestamp set for them, there's nothing I can really do about that. It'll never be null or missing for newly created threads though, if you have a newly created thread that has it missing/null, feel free to reopen though!

[advaith1]

@ajpalkovic the issue is that according to the documentation it can't be null (only absent), but the gateway behavior specifically is different

[ajpalkovic]

It's actually not even "gateway behavior", i bet something like thread_update would not set it to null, it's probably only guild_create and thread_list_sync that do, too bad. I could fix it, but caches, you know, so probably best just to say it can be null then if it's a problem for y'all?

[wasdennnoch]

While acceptable that caches may cache the invalid value for some time, it would be even better if the API was (eventually) consistent in when it sends which fields with what values.

[ajpalkovic]

For me it's more that: it's fixed for newly created threads and consistent for them, and all the old threads will eventually auto-archive anyway, so by the time that data is evicted from the "cache" they'll probably be archived anyway and it would be a moot point. And if I do fix this issue, it's just one line, it means that things would become more inconsistent because you cannot know if a given old thread will have null or have the field omitted.

So that's why I was leaning towards "do nothing", but LMK if you disagree.

[Quahu]

But this issue is simply prompted by the incorrect documentation. In my library that's statically typed this causes a deserialization error. If you intend to keep the behavior that doesn't match the docs that's fine, but don't close the issue until the documentation is amended. The issue was never about whether this behavior should change or not.

Description

ThreadMetadata#create_timestamp is documented as optional, non-nullable in the docs. With REST, it apparantly follows this documentation. However for gateway, it is sent as null in GUILD_CREATE's threads attribute.