mirror of
https://github.com/element-hq/synapse.git
synced 2026-10-23 19:33:44 +00:00
Fixes: #19661 Part of: MSC4354 First introduced some helpers for querying a sharded stream, which were moved to https://github.com/element-hq/synapse/pull/20108. - SQL builder for 'give me rows between two sharded tokens' - a function to return the 'new' from_token after a limited read Then make the sticky events portions of both oldschool and sliding sync use sharded tokens. This prevents a 'torn sync' problem where, because the events and sticky events streams are both sharded with the same writers: 1. persisting a sticky event leads to an event row and a `sticky_events` row being created for event `e` (on writer `W`). 2. Suppose another writer is still persisting, so the position of the stream for writer W advances, but the global ['linear'](https://element-hq.github.io/synapse/latest/development/synapse_architecture/streams.html?highlight=%E2%80%9Clinear%E2%80%9D#current-stream-id) (I have been calling this 'baseline') position does not advance yet. 3. sync is sharding-aware for the regular events stream, so `e` appears as a real-time timeline event, thus coming down sync 4. since sticky events were not sharding-aware, `e` is not detected as a sticky event in this sync response. The sticky event position doesn't advance in the sync token, either. 5. (assume the position advances because other writers have finished writing and so the 'linear' position advances for the sticky events stream) 6. the client then syncs again, using the new sync token. This time, `e` appears in the sticky event section. If we make sticky events sharding-aware in sync, then `e` would appear for consideration in both the timeline section **and** the sticky event section in the first sync. It then gets deduplicated out of the sticky section since it is appearing in the timeline section in the same sync. --------- Signed-off-by: Olivier 'reivilibre <oliverw@matrix.org> Co-authored-by: Eric Eastwood <erice@element.io>