You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Server A never notifies Server B of the disinvite (leave event), and therefore Server B can't really do anything about it. If the user tries to respond to the event, Server B could realize that 403 on join (or declination of the invite) means it should be locally rejected. At that point, you're in matrix-org/synapse#2181 territory.
When Server A is modified to make calls to Server B by sending the disinvite in a transaction, Server B accepts the transaction but ignores the event because it cannot determine the room version (and therefore the event format version). A lightly tested and highly unstable branch for modifying Server A to send the event is available here: matrix-org/synapse@16c8b4e...travis/fix-stuck-invites
Patching Server B's behaviour is non-trivial to me, otherwise I'd just fix it. Would be good if this fix was partnered with spec to clarify that disinvite (leave) events should be sent to target hosts, and that target hosts should expect them. I don't think this is introducing anything new, and shouldn't need a dedicated endpoint either.
The text was updated successfully, but these errors were encountered:
This issue has been migrated from #4808.
Riot issue: element-hq/element-web#7318
As mentioned in element-hq/element-web#7318 (comment), this is a different case from matrix-org/synapse#2181 due to Synapse not sending the disinvite over federation to the target homeserver.
As a simple test case:
Server A never notifies Server B of the disinvite (
leave
event), and therefore Server B can't really do anything about it. If the user tries to respond to the event, Server B could realize that 403 on join (or declination of the invite) means it should be locally rejected. At that point, you're in matrix-org/synapse#2181 territory.When Server A is modified to make calls to Server B by sending the disinvite in a transaction, Server B accepts the transaction but ignores the event because it cannot determine the room version (and therefore the event format version). A lightly tested and highly unstable branch for modifying Server A to send the event is available here: matrix-org/synapse@16c8b4e...travis/fix-stuck-invites
Patching Server B's behaviour is non-trivial to me, otherwise I'd just fix it. Would be good if this fix was partnered with spec to clarify that disinvite (leave) events should be sent to target hosts, and that target hosts should expect them. I don't think this is introducing anything new, and shouldn't need a dedicated endpoint either.
The text was updated successfully, but these errors were encountered: