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
{{ message }}
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
A user that has been invited can't join rooms if the person that sent the invitation already left the room.
We tried it by joining with /join/{roomId} and /rooms/{roomId}/join and both failed with {"errcode":"M_UNKNOWN","error":"No known servers"} as response content.
Steps to reproduce
User A creates a new room, inviting User B in the process
User A leaves the room
User B tries to join the room
We would have expected, that the join succeeds.
Version information
The Synapse we are currently using runs in a docker container (debian 10 slim) and is on version 1.25
Possible fix
We debugged the code a little and think we fixed the error in the following diff:
diff --git a/room_member.py b/room_member2.py
index cb5a29b..b2395de 100644
--- a/room_member.py+++ b/room_member2.py@@ -487,7 +487,10 @@ class RoomMemberHandler(metaclass=abc.ABCMeta):
# so don't really fit into the general auth process.
raise AuthError(403, "Guest access not allowed")
- if not is_host_in_room:+ inviter = await self._get_inviter(target.to_string(), room_id)+ inviter_is_local = inviter and self.hs.is_mine(inviter)++ if not is_host_in_room and not inviter_is_local:
if ratelimit:
time_now_s = self.clock.time()
(
@@ -502,8 +505,7 @@ class RoomMemberHandler(metaclass=abc.ABCMeta):
retry_after_ms=int(1000 * (time_allowed - time_now_s))
)
- inviter = await self._get_inviter(target.to_string(), room_id)- if inviter and not self.hs.is_mine(inviter):+ if inviter:
remote_room_hosts.append(inviter.domain)
content["membership"] = Membership.JOIN
The problem is that to join a room a server must join via a remote server already in the room, and so it needs to get a list of servers that are potentially in the room, e.g. when joining via an alias the server first asks the server that owns the alias for a list of servers in the room. For invites, the local server only knows about the server that sent the invite, so if it leaves the local server will run out of candidates to try and so the join fails.
This isn't ideal, and there are vague thoughts about trying to tell the invitee server about all members of the room, but there hasn't been any concrete proposals yet. This is tangentially related to #1533 and co, where you can't join rooms if everyone has left (even if the room is public).
I think your patch works by somehow joining the room locally? I'm a bit confused how that would work if the server hadn't been in it before?
I think this will require some spec changes to fix or make better, but this comes up periodically so I think we should leave it open as a tracking issue.
Our servers are isolated and don't use federation. Because of this the inviting server always has all the information aswell. This case should then be covered with the patch. But we could easily have misinterpreted something since we only do a deep dive into synapses code once or twice a year.
Description
A user that has been invited can't join rooms if the person that sent the invitation already left the room.
We tried it by joining with
/join/{roomId}
and/rooms/{roomId}/join
and both failed with{"errcode":"M_UNKNOWN","error":"No known servers"}
as response content.Steps to reproduce
We would have expected, that the join succeeds.
Version information
The Synapse we are currently using runs in a docker container (debian 10 slim) and is on version 1.25
Possible fix
We debugged the code a little and think we fixed the error in the following diff:
This might be a duplicate of #1533
The text was updated successfully, but these errors were encountered: