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

Commit fd2dadb

Browse files
author
David Robertson
authored
Adjust _get_rooms_changed comments (#11550)
C.f. #11494 (review)
1 parent f056218 commit fd2dadb

File tree

2 files changed

+30
-22
lines changed

2 files changed

+30
-22
lines changed

changelog.d/11550.misc

+1
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
Fix an inaccurate and misleading comment in the `/sync` code.

synapse/handlers/sync.py

+29-22
Original file line numberDiff line numberDiff line change
@@ -1662,20 +1662,20 @@ async def _get_rooms_changed(
16621662
) -> _RoomChanges:
16631663
"""Determine the changes in rooms to report to the user.
16641664
1665-
Ideally, we want to report all events whose stream ordering `s` lies in the
1666-
range `since_token < s <= now_token`, where the two tokens are read from the
1667-
sync_result_builder.
1665+
This function is a first pass at generating the rooms part of the sync response.
1666+
It determines which rooms have changed during the sync period, and categorises
1667+
them into four buckets: "knock", "invite", "join" and "leave".
16681668
1669-
If there are too many events in that range to report, things get complicated.
1670-
In this situation we return a truncated list of the most recent events, and
1671-
indicate in the response that there is a "gap" of omitted events. Additionally:
1669+
1. Finds all membership changes for the user in the sync period (from
1670+
`since_token` up to `now_token`).
1671+
2. Uses those to place the room in one of the four categories above.
1672+
3. Builds a `_RoomChanges` struct to record this, and return that struct.
16721673
1673-
- we include a "state_delta", to describe the changes in state over the gap,
1674-
- we include all membership events applying to the user making the request,
1675-
even those in the gap.
1676-
1677-
See the spec for the rationale:
1678-
https://spec.matrix.org/v1.1/client-server-api/#syncing
1674+
For rooms classified as "knock", "invite" or "leave", we just need to report
1675+
a single membership event in the eventual /sync response. For "join" we need
1676+
to fetch additional non-membership events, e.g. messages in the room. That is
1677+
more complicated, so instead we report an intermediary `RoomSyncResultBuilder`
1678+
struct, and leave the additional work to `_generate_room_entry`.
16791679
16801680
The sync_result_builder is not modified by this function.
16811681
"""
@@ -1686,16 +1686,6 @@ async def _get_rooms_changed(
16861686

16871687
assert since_token
16881688

1689-
# The spec
1690-
# https://spec.matrix.org/v1.1/client-server-api/#get_matrixclientv3sync
1691-
# notes that membership events need special consideration:
1692-
#
1693-
# > When a sync is limited, the server MUST return membership events for events
1694-
# > in the gap (between since and the start of the returned timeline), regardless
1695-
# > as to whether or not they are redundant.
1696-
#
1697-
# We fetch such events here, but we only seem to use them for categorising rooms
1698-
# as newly joined, newly left, invited or knocked.
16991689
# TODO: we've already called this function and ran this query in
17001690
# _have_rooms_changed. We could keep the results in memory to avoid a
17011691
# second query, at the cost of more complicated source code.
@@ -2009,6 +1999,23 @@ async def _generate_room_entry(
20091999
"""Populates the `joined` and `archived` section of `sync_result_builder`
20102000
based on the `room_builder`.
20112001
2002+
Ideally, we want to report all events whose stream ordering `s` lies in the
2003+
range `since_token < s <= now_token`, where the two tokens are read from the
2004+
sync_result_builder.
2005+
2006+
If there are too many events in that range to report, things get complicated.
2007+
In this situation we return a truncated list of the most recent events, and
2008+
indicate in the response that there is a "gap" of omitted events. Lots of this
2009+
is handled in `_load_filtered_recents`, but some of is handled in this method.
2010+
2011+
Additionally:
2012+
- we include a "state_delta", to describe the changes in state over the gap,
2013+
- we include all membership events applying to the user making the request,
2014+
even those in the gap.
2015+
2016+
See the spec for the rationale:
2017+
https://spec.matrix.org/v1.1/client-server-api/#syncing
2018+
20122019
Args:
20132020
sync_result_builder
20142021
ignored_users: Set of users ignored by user.

0 commit comments

Comments
 (0)