Synapse: 2 rooms with the same local alias

[PC-Admin]

Description

These 2 rooms have the same local address. o.0

!mqqiskmnpVkagrmQpW:perthchat.org (listed)
!DwUPBvNapIVecNllgt:perthchat.org (unlisted)

Are both mapped to #hello:perthchat.org

Half the time we try visit that local address users end up in the wrong room. Have changed the local address of the one we want to keep, strangely we can't remove the local address from the other undesired room, as you can see here:

Here is the unlisted room:

This is a freak bug and is un-reproducable, so perhaps you just want to ignore it.

Steps to reproduce

Not sure if this can be reproduced, seems like a freak once off bug.

Version information

• Homeserver: matrix.perthchat.org

• Version: 1.19.1

• Install method: Stantaleevs docker deploy script.

• Platform:
  Debian 10 with docker containers.

Element version: Element version: 1.7.8

[anoadragon453]

So we check whether a room alias exists already by relying on the database to raise an integrity error when we insert a new alias:

https://github.com/matrix-org/synapse/blob/da77520cd1c414c9341da287967feb1bab14cbec/synapse/storage/databases/main/directory.py#L126-L128

This works because there is a UNIQUE constraint for room_alias on the room_aliases table. It's possible that this constraint has been ignored and the insertion happened anyways.

Can you check if:

SELECT * FROM room_aliases WHERE room_alias = '#hello:perthchat.org';

returns two results? Can you also check whether the alias exists in room_alias_servers:

SELECT * FROM room_alias_servers WHERE room_alias = '#hello:perthchat.org';

[richvdh]

this sounds like a misunderstanding, and possibly a client-side bug. I would be very surprised if the server has actually ended up with one alias pointing at two rooms.

When you say "Half the time we try visit that local address": please can you explain exactly what you are doing, in which client, to cause this?

[PC-Admin]

Can you check if:

SELECT * FROM room_aliases WHERE room_alias = '#hello:perthchat.org';

returns two results? Can you also check whether the alias exists in room_alias_servers:

SELECT * FROM room_alias_servers WHERE room_alias = '#hello:perthchat.org';

It only returns 1 result, room_alias_servers also appears normal:

synapse=# SELECT * FROM room_aliases WHERE room_alias = '#hello:perthchat.org';
      room_alias      |              room_id              |         creator         
----------------------+-----------------------------------+-------------------------
 #hello:perthchat.org | !mqqiskmnpVkagrmQpW:perthchat.org | @PC-Admin:perthchat.org
(1 row)

synapse=# SELECT * FROM room_alias_servers WHERE room_alias = '#hello:perthchat.org';
      room_alias      |    server     
----------------------+---------------
 #hello:perthchat.org | perthchat.org
(1 row)

[PC-Admin]

this sounds like a misunderstanding, and possibly a client-side bug. I would be very surprised if the server has actually ended up with one alias pointing at two rooms.

When you say "Half the time we try visit that local address": please can you explain exactly what you are doing, in which client, to cause this?

Debian 10
Element-Web 1.7.5 in Firefox

By half the time, I mean for me it resolves properly, but for my friend @nug:perthchat.org it seems to resolve to the other room every time. He has both rooms open in his client, so perhaps this is why it keeps jumping him to the wrong room. (Well i say it's the wrong room, but in element-settings it still has #hello:perthchat.org as a local alias, even though the database says otherwise.)

@nug refreshing his client might solve the issue, but perhaps you have more questions about it first.

[richvdh]

By half the time, I mean for me it resolves properly,

what do you mean by "resolves properly"? Which buttons are you clicking? what are you typing? Which links are you following?

Alternatively: which synapse API calls are returning unexpected results?

[PC-Admin]

By half the time, I mean for me it resolves properly,

what do you mean by "resolves properly"? Which buttons are you clicking? what are you typing? Which links are you following?

Alternatively: which synapse API calls are returning unexpected results?

By 'resolved properly' i mean i get directed to the correct room after trying to join it. I click the #hello:perthchat.org link within the Element-desktop client. (v1.7.9, installed locally on Debian.)

@nug however clicks the same link in his Element-web client and is directed to the other room though. I suspect it's just a caching issue with his client. (v1.7.5, running on Firefox on Debian.)

[richvdh]

where do you both see this link?

[richvdh]

(a screenshot might be helpful, since words don't seem to be cutting it)

[anoadragon453]

It is a known problem that if an alias was edited on the server (possibly directly in the database) and that isn't propagated to clients, then upon clicking links/pills clients will still resolve to the old room ID.

That may be all that's happening here.

[richvdh]

@anoadragon453: so this is a client bug, in that it's assuming that the alias still points at the old room, rather than looking it up when the pill gets clicked?

I still wish we had a clear description of what the user is doing, rather than having to guess at it :/.

[PC-Admin]

where do you both see this link?

We simply write "#hello:perthchat.org" into any room, then click on it.

[richvdh]

ok, this sounds like a client issue. the client is incorrectly making assumptions about where the alias is pointing to. Please can you open an issue on the relevant client?