Add stream_ordering sort to Sliding Sync /sync

changelog.d/17293.feature

@@ -0,0 +1 @@
+Add recency sort to experimental [MSC3575](https://github.com/matrix-org/matrix-spec-proposals/pull/3575) Sliding Sync `/sync` endpoint.

synapse/handlers/sliding_sync.py

@@ -169,7 +169,7 @@ async def current_sync_for_user(
                 # `["m.room.member", "$LAZY"]`
                 filtered_room_ids = room_id_set
                 # TODO: Apply sorts
-                sorted_room_ids = sorted(filtered_room_ids)
+                sorted_room_ids = await self.sort_rooms(filtered_room_ids, to_token)
 
                 ops: List[SlidingSyncResult.SlidingWindowList.Operation] = []
                 if list_config.ranges:
@@ -439,3 +439,19 @@ async def get_sync_room_ids_for_user(
                 sync_room_id_set.add(room_id)
 
         return sync_room_id_set
+
+    async def sort_rooms(
+        self,
+        room_id_set: AbstractSet[str],
+        to_token: StreamToken,
+    ) -> List[str]:
+        """
+        Sort by recency of the last event in the room (stream_ordering). In order to get
+        a stable sort, we tie-break by room ID.
+
+        Args:
+            room_id_set: Set of room IDs to sort
+            to_token: We sort based on the events in the room at this token
+        """
+        # TODO: `get_last_event_in_room_before_stream_ordering()`
+        pass

synapse/storage/databases/main/stream.py

@@ -914,19 +914,21 @@ async def get_last_event_in_room_before_stream_ordering(
         def get_last_event_in_room_before_stream_ordering_txn(
             txn: LoggingTransaction,
         ) -> Optional[str]:
-            # We need to handle the fact that the stream tokens can be vector
-            # clocks. We do this by getting all rows between the minimum and
-            # maximum stream ordering in the token, plus one row less than the
-            # minimum stream ordering. We then filter the results against the
-            # token and return the first row that matches.
+            # We need to handle the fact that the stream tokens can be vector clocks. We
+            # do this by getting all rows between the minimum and maximum stream
+            # ordering in the token, plus one row less than the minimum stream ordering
+            # (TODO: Why?). We then filter the results against the token and return the
+            # first row that matches.
+            min_stream = end_token.stream
+            max_stream = end_token.get_max_stream_pos()
 
             sql = """
                 SELECT * FROM (
                     SELECT instance_name, stream_ordering, topological_ordering, event_id
                     FROM events
                     LEFT JOIN rejections USING (event_id)
                     WHERE room_id = ?
-                        AND ? < stream_ordering AND stream_ordering <= ?
+                        AND stream_ordering > ? AND stream_ordering <= ?
                         AND NOT outlier
                         AND rejections.event_id IS NULL
                     ORDER BY stream_ordering DESC
@@ -948,10 +950,10 @@ def get_last_event_in_room_before_stream_ordering_txn(
                 sql,
                 (
                     room_id,
-                    end_token.stream,
-                    end_token.get_max_stream_pos(),
+                    min_stream,
+                    max_stream,
                     room_id,
-                    end_token.stream,
+                    min_stream,
                 ),
             )
 

synapse/types/rest/client/__init__.py

@@ -175,20 +175,6 @@ class SlidingSyncList(CommonRoomParameters):
             ranges: Sliding window ranges. If this field is missing, no sliding window
                 is used and all rooms are returned in this list. Integers are
                 *inclusive*.
-            sort: How the list should be sorted on the server. The first value is
-                applied first, then tiebreaks are performed with each subsequent sort
-                listed.
-
-                    FIXME: Furthermore, it's not currently defined how servers should behave
-                    if they encounter a filter or sort operation they do not recognise. If
-                    the server rejects the request with an HTTP 400 then that will break
-                    backwards compatibility with new clients vs old servers. However, the
-                    client would be otherwise unaware that only some of the sort/filter
-                    operations have taken effect. We may need to include a "warnings"
-                    section to indicate which sort/filter operations are unrecognised,
-                    allowing for some form of graceful degradation of service.
-                    -- https://github.com/matrix-org/matrix-spec-proposals/blob/kegan/sync-v3/proposals/3575-sync.md#filter-and-sort-extensions
-
             slow_get_all_rooms: Just get all rooms (for clients that don't want to deal with
                 sliding windows). When true, the `ranges` and `sort` fields are ignored.
             required_state: Required state for each room returned. An array of event
@@ -253,7 +239,6 @@ class Filters(RequestBodyModel):
             ranges: Optional[List[Tuple[int, int]]] = None
         else:
             ranges: Optional[List[Tuple[conint(ge=0, strict=True), conint(ge=0, strict=True)]]] = None  # type: ignore[valid-type]
-        sort: Optional[List[StrictStr]] = None
         slow_get_all_rooms: Optional[StrictBool] = False
         include_heroes: Optional[StrictBool] = False
         filters: Optional[Filters] = None