Edit history

1. Run a bot with 2 shards (shard: [0, 2] and shard: [1, 2]) and keep both sessions connected.
2. Take a guild that belongs to the shard whose session identified second, so the guild is missing from the presence guild_ids.
3. Kick the bot from that guild.
4. Invite the bot to the guild again.
5. Send a message in the guild.

Summary

Setup

• Bot with 2 shards (shard: [0, 2] and shard: [1, 2]), about 2100 guilds
• Both sessions stay connected for days, with resumes and the occasional fresh identify on either side

What happened

• Shard 1 received GUILD_CREATE for the guild at 2026-10-28T09:17:44Z. The member's joined_at matches to the second.
• Shard 0 received neither GUILD_DELETE for the kick nor GUILD_CREATE for the re-join.
• From then on no MESSAGE_CREATE or other event of that guild reached shard 0, so the bot stopped responding there.
• I restarted shard 0. A fresh identify builds the guild list from the database again, so the guild is back on the right session.

Cause

1. The presence takes its guild_ids from the session that starts it. That list is already filtered to the session's shard:
   • session_connection_presence.erl#L58-L64
   • presence_manager_shard.erl#L166
2. Later sessions of the same user adopt the running presence. Their guild IDs are never merged in:
   • presence_manager_shard.erl#L209
3. On kick, handle_leave_guild does not find the guild in guild_ids, so no guild_leave goes to the sessions:
   • presence_connect.erl#L74
4. The guild process still drops every session of the kicked user:
   • guild_state.erl#L194
   • guild_state_member.erl#L125
   • The owning session keeps its {Pid, Ref} entry in guilds, because the guild process is still alive and nothing told the session to remove it.
5. On re-join, handle_join_guild adds the guild and sends guild_join to all sessions:
   • presence_connect.erl#L62
   • The session of the other shard has no entry, connects and gets GUILD_CREATE.
   • The owning session finds its stale entry and returns without connecting: session_connection_guild.erl#L44-L50

Reproduced against the gateway code

== 1. identify filter (gateway_sharding)
shard 0 guilds: [1488115521506995110,1474874137937518680]
shard 1 guilds: [1485394316330348923,1564551479656722433]
== 2. presence guild_ids (session_visits:member_guild_ids + presence_manager_shard)
shard 1 then shard 0 get the same presence: true
presence guild_ids: [1485394316330348923,1564551479656722433]
== 3. kick from shard 0 guild 1488115521506995110 (presence leave_guild cast)
shard 0 session got: []
shard 1 session got: []
   control: kick from shard 1 guild 1485394316330348923
shard 0 session got: [{guild_leave,1485394316330348923}]
shard 1 session got: [{guild_leave,1485394316330348923}]
== 4. guild process removes the kicked member's sessions (guild_state_member)
guild sessions before: [<<"other-user">>,<<"session-shard-0">>]
guild sessions after:  [<<"other-user">>]
messages the shard 0 session got from this: []
== 5. re-invite (presence join_guild cast)
shard 0 session got: [{guild_join,1488115521506995110}]
shard 1 session got: [{guild_join,1488115521506995110}]
== 6. sessions handle guild_join (session:handle_cast + handle_info guild_connect)
shard 0 session: #{connect_started => false, guild_entry => {<0.88.0>,#Ref<...>}, state_unchanged => true}
shard 1 session: #{connect_started => true, guild_entry => no_entry_yet, state_unchanged => false}

Possible fixes

• Merge the session's guild_ids into the presence when a session adopts an existing presence. Removing them again when a session disconnects would also be needed, otherwise a guild that only one session knows can stay in the list. Either way the presence should hold the union of all its sessions' guilds.
• In addition or instead, handle_guild_connect could check whether the guild process still has the session subscribed before it treats an existing {Pid, Ref} as connected.