@@ -1662,20 +1662,20 @@ async def _get_rooms_changed(
1662
1662
) -> _RoomChanges :
1663
1663
"""Determine the changes in rooms to report to the user.
1664
1664
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" .
1668
1668
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.
1672
1673
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`.
1679
1679
1680
1680
The sync_result_builder is not modified by this function.
1681
1681
"""
@@ -1686,16 +1686,6 @@ async def _get_rooms_changed(
1686
1686
1687
1687
assert since_token
1688
1688
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.
1699
1689
# TODO: we've already called this function and ran this query in
1700
1690
# _have_rooms_changed. We could keep the results in memory to avoid a
1701
1691
# second query, at the cost of more complicated source code.
@@ -2009,6 +1999,23 @@ async def _generate_room_entry(
2009
1999
"""Populates the `joined` and `archived` section of `sync_result_builder`
2010
2000
based on the `room_builder`.
2011
2001
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
+
2012
2019
Args:
2013
2020
sync_result_builder
2014
2021
ignored_users: Set of users ignored by user.
0 commit comments