Rooms can't be publicly joined if nobody from the originating homeserver is in them

[mashedkeyboard]

Description

Some particularly strange behaviour when using federated rooms... best illustrated by the steps below:

Steps to reproduce

• User A, from homeserver a, creates room 1 as a public room.
• User B, from homeserver b, joins room 1.
• User A leaves room 1.
• User B is still in room 1, and any user on homeserver b can peek room 1. User B can send messages into room 1 as normal.
• User A cannot rejoin room 1, and no new users on homeserver a can either; they all get an error {"errcode":"M_UNKNOWN","error":"No known servers"} on trying to do so. Room 1 is not visible in homeserver a's list of public rooms, either.
• Users on any homeserver other than a cannot join room 1 either; they would get an error {"errcode":"M_NOT_FOUND","error":"Not an active room on this server"}.
• Attempting to create a new room with the same name on homeserver a results in an error, as _matrix/client/r0/directory/room/#1:a.homeserver returns {"room_id":"!theId:a.homeserver","servers":["a.homeserver"]}
• If user B invites user A back to room 1, user A can join room 1 just fine(!)

I hope it goes without saying that this is rather bizarre behaviour 😅

Version information

• Homeserver: mashed.cloud, but also replicated on another different server

If not matrix.org:

• Version: 1.56.0

• Install method: package manager (Matrix.org debian packages)

• Platform: Ubuntu Linux 20.04.4 (Linux 5.4.0-107-generic on x86_64) running on a virtual private server

[mashedkeyboard]

Workaround:

• User B sends an invite to the room to user C, from homeserver a.
• User C joins the room successfuly from the invite.
• User A can now join the room without being invited.

So it looks like the process of inviting someone from homeserver a might "reset" the way that homeserver a sees the room? I'm not really sure how this works from a technical perspective, though.

Note that this relies on user B having permissions to create invites. If user A was the only user who can create invites, then this won't work, and the room is stuck in limbo.

[dinosmm]

We've replicated this on my own homeserver too, exactly the same behaviour (also on 1.56.0, installed from deb packages, ubuntu 20.04).

In addition to the original post, it seems that user A cannot rejoin the room until another user from the same homeserver is invited and joins. Then, user A can immediately rejoin the room, with an invite or just by using the room name/link.

[DMRobertson]

Related: #9555 #1533

[DMRobertson]

User A cannot rejoin room 1, and no new users on homeserver a can either; they all get an error {"errcode":"M_UNKNOWN","error":"No known servers"} on trying to do so. Room 1 is not visible in homeserver a's list of public rooms, either.

It's important to understand here exactly how you try to rejoin the room from homeserver a. Are you trying to join via an alias, e.g. #roomname:server-a?

[reivilibre]

At a first guess I'd say you're trying to join using the Room ID, but haven't told it any known servers in the room.
A homeserver can't join a room it doesn't know about unless it knows where it can find out about the room.
In matrix.to URLs that use room IDs (!blahblah:blah), this is what the ?via parameter(s) is/are about, e.g. https://matrix.to/#/!EIcIdEmAuTlbfObBIr:librepush.net?via=librepush.net&via=element.io.
Otherwise, using a room alias (#blahblah:blah) is best because the server name within the alias is a known server that knows about the room.

As the comment above this one says, knowing how exactly you're rejoining the room is important. If you're not typing in the room ID manually, it's possibly a client bug.

[mashedkeyboard]

Yes, joining via a room alias just like that. As a user, it makes little sense for the room to continue to have that alias assigned to it on other homeservers if the homeserver that the alias belongs to has left, at least to my thinking; would it not make more sense either for Synapse to "forward" requests for that room to another server still in the room, or for the room's ID to update to another homeserver when it leaves?

The latter of those two options might be a spec change rather than a Synapse change, though, I guess.

[byanes]

Seeing something similar to this, joining room via room alias and running Synapse v1.54.0.

User A, creates room and invites user B to join
User A leaves the room before User B has joined
User B tries to join the room

The error being thrown: {"errcode":"M_UNKNOWN","error":"No known servers"}

Looks like this can be related to #9688 and #1533

[aaronraimist]

Maybe I am misunderstanding but the title of the issue seems to be a bit misleading. The problem actually seems to be: Aliases on a homeserver stop working when all users from that homeserver leave the room.

The room isn't unjoinable. Users can still join by using an alias on another server, receiving an invite, or using the room ID if you know the appropriate via servers.

One solution would be to automatically delete aliases when all users from a homeserver have left a room #1201

Alternatively #9555 (comment) points out that Synapse could continue to handle alias queries even after it has left the room. It's true the homeserver could provide the room ID but it wouldn't be able to give an up to date list of servers that are in the room to join through. This also wouldn't work once #4720 has been implemented.

[richvdh]

I think this is just a duplicate of #9555?