Delayed membership responses in /sync cause UTDs

[kegsay]

This outlines a race condition in the CSAPI which can cause UTDs.

Consider:

• Alice is in a E2EE room and invites Bob. The request 200 OKs but has yet to come down /sync.
  • Alice tries to send a message in the room.
  • Alice should encrypt for Bob.

In practice, clients will not encrypt for Bob, causing a UTD if you very quickly send an encrypted message after inviting a user. This can happen due to:

• A bot is using the SDK so message sending is very quick after an invite
• DMs: for better UX a room is only made / user invited / message sent, when someone sends a message in a DM room rather than just selects the user's room. This means the message is already ready to go at the same time as invite time.

To fix this, we should be remembering that we, the client, have modified the membership state of the room, and invalidate the room member list (so we hit /members again). We can't assume that a 200 OK to /invite will guarantee that the user is in an invited state, so we still need to defer to the server.

A test for this is in https://github.com/matrix-org/complement-crypto/pull/98

[richvdh]

To fix this, we should be remembering that we, the client, have modified the membership state of the room, and invalidate the room member list (so we hit /members again).

Possibly, though the race isn't limited to this case: it's always possible for a membership change to happen in the room at the same time as we send a message, whether or not we caused that membership change.

I'd argue this is just a special-case of https://github.com/element-hq/element-meta/issues/2268 and a fix to that would fix this particular case.

(With that said, fixing this particular case is probably easier than a more general fix so may be worthwhile anyway.)

[kegsay]

it's always possible for a membership change to happen in the room at the same time as we send a message, whether or not we caused that membership change.

I agree, but that is fundamentally non-deterministic as senders/receivers don't synchronise in any way. For this issue, it can be and bots/scripts/apps expect it to be deterministic.