diff options
author | Eric Eastwood <eric.eastwood@beta.gouv.fr> | 2024-08-07 11:27:50 -0500 |
---|---|---|
committer | GitHub <noreply@github.com> | 2024-08-07 11:27:50 -0500 |
commit | 11db575218d2601384e05519a45d930f34d0b1ae (patch) | |
tree | 036a28ffa2be081e419293b33448cbca4ec406f2 /docs | |
parent | Bump bytes from 1.6.1 to 1.7.1 (#17526) (diff) | |
download | synapse-11db575218d2601384e05519a45d930f34d0b1ae.tar.xz |
Sliding Sync: Use `stream_ordering` based timeline pagination for incremental sync (#17510)
Use `stream_ordering` based `timeline` pagination for incremental `/sync` in Sliding Sync. Previously, we were always using a `topological_ordering` but we should only be using that for historical scenarios (initial `/sync`, newly joined, or haven't sent the room down the connection before). This is slightly different than what the [spec suggests](https://spec.matrix.org/v1.10/client-server-api/#syncing) > Events are ordered in this API according to the arrival time of the event on the homeserver. This can conflict with other APIs which order events based on their partial ordering in the event graph. This can result in duplicate events being received (once per distinct API called). Clients SHOULD de-duplicate events based on the event ID when this happens. But we've had a [discussion below in this PR](https://github.com/element-hq/synapse/pull/17510#discussion_r1699105569) and this matches what Sync v2 already does and seems like it makes sense. Created a spec issue https://github.com/matrix-org/matrix-spec/issues/1917 to clarify this. Related issues: - https://github.com/matrix-org/matrix-spec/issues/1917 - https://github.com/matrix-org/matrix-spec/issues/852 - https://github.com/matrix-org/matrix-spec-proposals/pull/4033
Diffstat (limited to 'docs')
-rw-r--r-- | docs/development/room-dag-concepts.md | 6 |
1 files changed, 4 insertions, 2 deletions
diff --git a/docs/development/room-dag-concepts.md b/docs/development/room-dag-concepts.md index 76709487f8..35b667831c 100644 --- a/docs/development/room-dag-concepts.md +++ b/docs/development/room-dag-concepts.md @@ -21,8 +21,10 @@ incrementing integer, but backfilled events start with `stream_ordering=-1` and --- - - `/sync` returns things in the order they arrive at the server (`stream_ordering`). - - `/messages` (and `/backfill` in the federation API) return them in the order determined by the event graph `(topological_ordering, stream_ordering)`. + - Incremental `/sync?since=xxx` returns things in the order they arrive at the server + (`stream_ordering`). + - Initial `/sync`, `/messages` (and `/backfill` in the federation API) return them in + the order determined by the event graph `(topological_ordering, stream_ordering)`. The general idea is that, if you're following a room in real-time (i.e. `/sync`), you probably want to see the messages as they arrive at your server, |