-
-
Notifications
You must be signed in to change notification settings - Fork 2.1k
Track device list updates per room. #12321
Conversation
Currently we update the `device_lists_outbound_pokes` at the same time as `device_lists_changes_in_room`, but in future we'll do them at different times.
78e2c0a
to
7707cab
Compare
7707cab
to
f8af30f
Compare
0af131a
to
7266580
Compare
await self.db_pool.runInteraction( | ||
"add_device_change_to_stream", | ||
self._add_device_change_to_stream_txn, | ||
num_stream_ids = max( |
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.
it might be good to add a comment clarifying why this is a max
rather than a total (vis, that we use the same set of stream ids for each of the three tables)
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.
The max
got replaced, but I've added a comment the equivalent code
synapse/storage/schema/main/delta/69/01device_list_oubound_by_room.sql
Outdated
Show resolved
Hide resolved
synapse/storage/schema/main/delta/69/01device_list_oubound_by_room.sql
Outdated
Show resolved
Hide resolved
"stream_id": stream_id, | ||
"room_id": room_id, | ||
}, | ||
updatevalues={"converted_to_destinations": True}, |
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.
this might be a silly question, but why do we do it this way, instead of keeping track of the point we've processed up 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.
Err, we could. I don't think I had much reasoning beyond not having to worry about extra tables or handling the duplicate stream IDs.
I've also been thinking about how you'd distribute this across multiple workers, but I'm not sure this helps that or not 🤷
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.
mmmhmm. Generally I prefer to keep our tables append-only where possible (it saves a world of caching problems later on), but fair enough.
synapse/handlers/device.py
Outdated
joined_users = await self.store.get_users_in_room(room_id) | ||
hosts.update(get_domain_from_id(u) for u in joined_users) | ||
hosts: Optional[Set[str]] = None | ||
if self.use_new_device_lists_changes_in_room: |
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.
is this the wrong way round? we should skip calculating hosts if use_new_device_lists_changes_in_room
?
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.
Bah, yes. And this is the only place that uses it directly ─ everything else infers it from hosts
being None
─ so nothing broke.
I'm not sure if there is an easy way to test that this is the right way round?
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.
you might be able to block the _handle_new_device_update_async
job in the tests (eg by setting _handle_new_device_update_is_processing
), and check what actually gets written to the db?
Not sure it's worth it though.
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 guess this code is going to be ripped out in the next release anyway
…room.sql Co-authored-by: Richard van der Hoff <[email protected]>
…room.sql Co-authored-by: Richard van der Hoff <[email protected]>
(The last three commits are bug fixes, rather than responding to review comments) |
synapse/storage/schema/main/delta/69/01device_list_oubound_by_room.sql
Outdated
Show resolved
Hide resolved
"stream_id": stream_id, | ||
"room_id": room_id, | ||
}, | ||
updatevalues={"converted_to_destinations": True}, |
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.
mmmhmm. Generally I prefer to keep our tables append-only where possible (it saves a world of caching problems later on), but fair enough.
# No changes to notify about, so this is a no-op. | ||
return | ||
|
||
users_who_share_room = await self.store.get_users_who_share_room_with_user( |
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.
FederationSenderDevicesTestCases still stubs this out. Is that still necessary?
synapse/handlers/device.py
Outdated
joined_users = await self.store.get_users_in_room(room_id) | ||
hosts.update(get_domain_from_id(u) for u in joined_users) | ||
hosts: Optional[Set[str]] = None | ||
if self.use_new_device_lists_changes_in_room: |
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.
you might be able to block the _handle_new_device_update_async
job in the tests (eg by setting _handle_new_device_update_is_processing
), and check what actually gets written to the db?
Not sure it's worth it though.
-- This initialy matches `device_lists_stream.stream_id`. Note that we | ||
-- delete older values from `device_lists_stream`, so we can't use a foreign | ||
-- constraint here. |
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.
this is no longer true as of cf04f1a, right?
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.
That commit is about device_list_outbound_pokes
? Rather than device_lists_stream
or device_lists_changes_in_room
?
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.
oh. confused. sorry.
Co-authored-by: Richard van der Hoff <[email protected]>
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!
|
||
async def get_uncoverted_outbound_room_pokes( | ||
self, limit: int = 10 | ||
) -> List[Tuple[str, str, str, int, Optional[Dict[str, str]]]]: |
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 think the return type here is incorrect: the optional dict should be Optional[str]. (Presumably we json-decode the string elsewhere when needed.)
Xref #12485 (comment)
This is a first step in dealing with #7721.
The idea is basically that rather than calculating the full set of users a device list update needs to be sent to up front, we instead simply record the rooms the user was in at the time of the change. This will allow a few things:
/sync
and/keys/changes
we can avoid also avoid calculating users who share rooms with other users, and instead just look at the rooms that have changed.However, care needs to be taken to correctly handle server downgrades. As such this PR writes to both
device_lists_changes_in_room
and thedevice_lists_outbound_pokes
table synchronously. In a future release we can then bump the database schema compat version to69
and then we can assume that the newdevice_lists_changes_in_room
exists and is handled.There is a temporary option to disable writing to
device_lists_outbound_pokes
synchronously, allowing us to test the new code path does work (and by implication upgrading to a future release and downgrading to this one will work correctly).Note: Ideally we'd do the calculation of room to servers on a worker (e.g. the background worker), but currently only master can write to the
device_list_outbound_pokes
table.Reviewable commit-by-commit.