This repository has been archived by the owner on Apr 26, 2024. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Presence
should send less presence when joining a room #15818Presence
should send less presence when joining a room #15818Changes from 6 commits
058ad9f
7c6095b
b286a48
389b9a2
6e090b1
51ce7f5
6ee0d4f
5284e65
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
I'm not following this, why are we comparing all users previously in the room to see if they share a room? Notably, I think both
user_id
andother_user_id
can be remote users?I'd have thought that at least one iteration here should be across the newly joined users or hosts?
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.
Excellent question. We want to build a full list of all remote servers in the room, not the actual users. (We shortcut out so not to hit the database more than necessary). But, we want the list to excluded some servers, hence the comparison. The list needs to be both as full as possible and as empty as possible at the same time.
Not just can be, they are. It means that we know the host from
user_id
is in this room, but ifother_user_id
's host(which we know is in this room obviously) is in yet another room that we know about because it's federated to this server, thanuser_id
's host can be excluded, since they are already receiving presence. For example:@me:myserver
,@alice:server1
and@bob:server2
are already inSynapse Admins
.@me:myserver
,@bob:server2
and@charlie:server2
are inMatrix HQ
.@alice:server1
is joiningMatrix HQ
.Because we know
server1
is already receiving presence info about@bob:server2
, it can be excluded from the list ofprev_remote_hosts
.In retrospect, perhaps an additional list maintaining all the hosts we know can be excluded would also be a good idea, to cut down on database hits? However, I see a potential gotcha here, as what happens to
@charlie:server2
? If we maintain an excluded list as well, he would never be checked against and therefore(at least at first) not receive the new presence data.(Depending of course on if@bob
or@charlie
is checked first)Newly joined(either local or remote) is dealt with in the next block below, starting at about line 1496.
It could actually be argued that presence would be retrieved on the first(next?) sync that occurs after the room is fully joined anyways, so why are we bothering with this at all?
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.
I had an epiphany while at work tonight; the
prev_remote_hosts
only needs to be built if one of the newly joined users is local. If that's what you were getting at with your question, mission accomplished 😉. I'll do a refactor in a bit.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.
I still want to make this optimization a thing, but perhaps it's best left to another PR. If that's ok?Nope, never mind. Still need it after all. Testing is great. Can't whittle down the list if we don't have the data. I'm still gonna ponder on this, but right now it's not easily actionable.