if /send_join fails, you end up half-joined to a room

[richvdh]

if you send a /send_join request which times out (or your server/connection dies before you receive the response), then you end up in a situation where the remote server thinks you have joined the room, but the local server doesn't.

In synapse at least, that means that you end up with a bunch of Ignoring PDU for unknown room_id: !room_id warnings.

[richvdh]

I'm not really sure what would be better... maybe adding yet another phase to the join dance would at least reduce the likelihood of it being a problem?

[richvdh]

(I feel like we might already have an issue tracking this somewhere, so if anyone can find one please link it)

[neilalexander]

In the past we've talked about a possible three-way handshake, as a confirmation step once the room state has been successfully processed.

Potential option 1:

• Server A sends a make join request to server B, like today
• Server A requests the room state and auth chain from server B
• Server A sends the membership event to all servers in the room based on the returned state, rather than server B doing it

Potential option 2:

• Server A sends a make join request to server B, like today
• Server A sends a send join to server B, like today, but server B queues the membership event rather than sending it
• Server A sends a confirm join to server B, at which point server B sends the new membership event into the room

[ShadowJonathan]

@neilalexander with option 2, isnt it possible that server A is continually receiving new room state, while no member is part of that room from that server, but that effectively A could be continually polling new room info from server B, while never having a member "confirm join" that room?