Skip to content
This repository has been archived by the owner on Apr 26, 2024. It is now read-only.

Adjust _get_rooms_changed comments #11550

Merged
merged 3 commits into from
Dec 10, 2021
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
1 change: 1 addition & 0 deletions changelog.d/11550.misc
Original file line number Diff line number Diff line change
@@ -0,0 +1 @@
Fix an inaccurate and misleading comment in the `/sync` code.
51 changes: 29 additions & 22 deletions synapse/handlers/sync.py
Original file line number Diff line number Diff line change
Expand Up @@ -1662,20 +1662,20 @@ async def _get_rooms_changed(
) -> _RoomChanges:
"""Determine the changes in rooms to report to the user.

Ideally, we want to report all events whose stream ordering `s` lies in the
range `since_token < s <= now_token`, where the two tokens are read from the
sync_result_builder.
This function is a first pass at generating the rooms part of the sync response.
It determines which rooms have changed during the sync period, and categorises
them into four buckets: "knock", "invite", "join" and "leave".

If there are too many events in that range to report, things get complicated.
In this situation we return a truncated list of the most recent events, and
indicate in the response that there is a "gap" of omitted events. Additionally:
1. Finds all membership changes for the user in the sync period (from
`since_token` up to `now_token`).
2. Uses those to place the room in one of the four categories above.
3. Builds a `_RoomChanges` struct to record this, and return that struct.

- we include a "state_delta", to describe the changes in state over the gap,
- we include all membership events applying to the user making the request,
even those in the gap.

See the spec for the rationale:
https://spec.matrix.org/v1.1/client-server-api/#syncing
Comment on lines -1665 to -1678
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It feels like the removed stuff was correct and maybe useful? YMMV though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, maybe I can find a better place for it.

For rooms classified as "knock", "invite" or "leave", we just need to report
a single membership event in the eventual /sync response. For "join" we need
to fetch additional non-membership events, e.g. messages in the room. That is
more complicated, so instead we report an intermediary `RoomSyncResultBuilder`
struct, and leave the additional work to `_generate_room_entry`.

The sync_result_builder is not modified by this function.
"""
Expand All @@ -1686,16 +1686,6 @@ async def _get_rooms_changed(

assert since_token

# The spec
# https://spec.matrix.org/v1.1/client-server-api/#get_matrixclientv3sync
# notes that membership events need special consideration:
#
# > When a sync is limited, the server MUST return membership events for events
# > in the gap (between since and the start of the returned timeline), regardless
# > as to whether or not they are redundant.
#
# We fetch such events here, but we only seem to use them for categorising rooms
# as newly joined, newly left, invited or knocked.
# TODO: we've already called this function and ran this query in
# _have_rooms_changed. We could keep the results in memory to avoid a
# second query, at the cost of more complicated source code.
Expand Down Expand Up @@ -2009,6 +1999,23 @@ async def _generate_room_entry(
"""Populates the `joined` and `archived` section of `sync_result_builder`
based on the `room_builder`.

Ideally, we want to report all events whose stream ordering `s` lies in the
range `since_token < s <= now_token`, where the two tokens are read from the
sync_result_builder.

If there are too many events in that range to report, things get complicated.
In this situation we return a truncated list of the most recent events, and
indicate in the response that there is a "gap" of omitted events. Lots of this
is handled in `_load_filtered_recents`, but some of is handled in this method.

Additionally:
- we include a "state_delta", to describe the changes in state over the gap,
- we include all membership events applying to the user making the request,
even those in the gap.

See the spec for the rationale:
https://spec.matrix.org/v1.1/client-server-api/#syncing

Args:
sync_result_builder
ignored_users: Set of users ignored by user.
Expand Down