-
-
Notifications
You must be signed in to change notification settings - Fork 585
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Delayed membership responses in /sync cause UTDs #4291
Comments
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 element-hq/element-meta#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.) |
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. |
This outlines a race condition in the CSAPI which can cause UTDs.
Consider:
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:
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 matrix-org/complement-crypto#98
The text was updated successfully, but these errors were encountered: