ETF gateway leaks Guild.Models.IncidentsData

[jchristgit]

Description

The ETF gateway leaks a Guild.Models.IncidentsData struct under the incidents_data key causing Elixir's built-in enumeration to raise.
This field does not seem to be documented in the API so I believe this is a bug. See Kraigie/nostrum#511

Steps to Reproduce

Currently unclear, I assume this field is sent as part of a GUILD_UPDATE or a new undocumented event.

A similar issue can be found at #4196.

Expected Behavior

No :__struct__ keys are sent over the ETF gateway for any maps.

Current Behavior

The following payload was received over the gateway:

incidents_data: %{
      __struct__: Guilds.Models.IncidentsData,
      dm_spam_detected_at: nil,
      dms_disabled_until: nil,
      invites_disabled_until: nil,
      raid_detected_at: nil
    },

A full stacktrace (with nostrum's guts):

[error] GenServer #PID<0.9674.0> terminating
** (Protocol.UndefinedError) protocol Enumerable not implemented for %{__struct__: Guilds.Models.IncidentsData, dm_spam_detected_at: nil, dms_disabled_until: nil, invites_disabled_until: nil, raid_detected_at: nil} of type Guilds.Models.IncidentsData (a struct)
    (elixir 1.14.5) lib/enum.ex:1: Enumerable.impl_for!/1
    (elixir 1.14.5) lib/enum.ex:166: Enumerable.reduce/3
    (elixir 1.14.5) lib/enum.ex:4307: Enum.reduce/3
    (nostrum 0.8.0) lib/nostrum/util.ex:153: Nostrum.Util.safe_atom_map/1
    (nostrum 0.8.0) lib/nostrum/util.ex:153: anonymous fn/2 in Nostrum.Util.safe_atom_map/1
    (stdlib 4.3.1) maps.erl:411: :maps.fold_1/3
    (nostrum 0.8.0) lib/nostrum/util.ex:153: Nostrum.Util.safe_atom_map/1
    (nostrum 0.8.0) lib/nostrum/util.ex:153: anonymous fn/2 in Nostrum.Util.safe_atom_map/1
    (stdlib 4.3.1) maps.erl:411: :maps.fold_1/3
    (nostrum 0.8.0) lib/nostrum/util.ex:153: Nostrum.Util.safe_atom_map/1
    (nostrum 0.8.0) lib/nostrum/shard/event.ex:13: Nostrum.Shard.Event.handle/3
    (nostrum 0.8.0) lib/nostrum/shard/session.ex:103: Nostrum.Shard.Session.handle_info/2
    (stdlib 4.3.1) gen_server.erl:1123: :gen_server.try_dispatch/4
    (stdlib 4.3.1) gen_server.erl:1200: :gen_server.handle_msg/6
    (stdlib 4.3.1) proc_lib.erl:240: :proc_lib.init_p_do_apply/3
Last message: {:gun_ws, #PID<0.9676.0>, #Reference<0.2461590911.3585343490.220956>, {:binary, <<236, 125, 11, 124, 20, 213, 213, 248, 36, 44, 73, 72, 66, 178, 64, 64, 65, 133, 65, 107, 5, 36, 113, 94, 251, 138, 80, 54, 201, 134, 16, 75, 96, 73, 2, 40, 98, 151, 217, 221, 217, 236, 192, 238, ...>>}}
State: %Nostrum.Struct.WSState{shard_num: 0, total_shards: 1, seq: 1, session: "7849acc5c0ce6e80fb58cc770b9c6238", shard_pid: nil, conn: #PID<0.9676.0>, conn_pid: #PID<0.9674.0>, stream: #Reference<0.2461590911.3585343490.220956>, gateway: "gateway.discord.gg/?compress=zlib-stream&encoding=etf&v=10", last_heartbeat_send: ~U[2023-06-15 10:44:23.340796Z], last_heartbeat_ack: ~U[2023-06-15 10:44:23.489435Z], heartbeat_ack: true, heartbeat_interval: 41250, heartbeat_ref: {:once, #Reference<0.2461590911.3585343490.220960>}, zlib_ctx: #Reference<0.2461590911.3585474562.220958>}

Screenshots/Videos

No response

Client and System Information

nostrum 0.8.0

[mezz]

Thanks for the report! We'll work on a fix.

In the meantime, to make your system more robust against mistakes like this, you can check is_struct(data) and then do Map.from_struct(data) and log a warning. That way you can still see and report issues to us, but it will not crash your library.

[jchristgit]

Thank you for the tip, will do that 🙂