-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
On upgrade room only send canonical alias once. #7547
Conversation
Instead of doing a complicated dance of deleting and moving aliases one by one, which sends a canonical alias update into the old room for each one, lets do it all in one go. This also changes the function to move *all* local alias events to the new room, however that happens later on anyway.
cf49e61
to
25f3f41
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks fine from a python and room upgrade perspective, but I'd like to get someone more familiar with the new alias semantics to review as well.
I believe this is keeping existing behaviour, we have some pretty detailed sytests for this. Note that the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes a lot more sense on the second go around. Just had a quick question.
new_canonical_alias_content = {} | ||
|
||
canonical = canonical_alias_event.content.get("alias") | ||
if canonical and self.hs.is_mine_id(canonical): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Are we not able to move canonical aliases if they don't belong to us? It's kind of annoying if the person upgrading a room (with canonical alias #project:matrix.org
for visibility) has to move it via their matrix.org account.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we check the canonical alias event to make sure that all the aliases listed do actually point to the room. We can't a) move aliases that don't belong to the server, nor b) set the canonical alias if its still pointing to the old room (and I'm not sure we'd want to).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, yes of course. So in this case the room will be upgraded, and the alias will be left behind until someone from the server that owns it, moves it.
That actually does sound intuitive.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm then!
Instead of doing a complicated dance of deleting and moving aliases one by one, which sends a canonical alias update into the old room for each one, lets do it all in one go. This also changes the function to move *all* local alias events to the new room, however that happens later on anyway.
Instead of doing a complicated dance of deleting and moving aliases one
by one, which sends a canonical alias update into the old room for each
one, lets do it all in one go.
This also changes the function to move all local alias events to the new
room, however that happens later on anyway.