Description
This issue is meant to track the gradual migration so that the application code can fully rely on the sliding_sync_joined_rooms/sliding_sync_membership_snapshots database tables.
(an example of gradually migrating to a completely new database table)
Synapse version N + 1
This step was done in #17512 (landed in Synapse vTODO)
The N+1 step introduces the sliding_sync_joined_rooms/sliding_sync_membership_snapshots tables and background updates to populate those tables over time. SCHEMA_VERSION was bumped to 87.
Since we always make sure to fully insert a row if it doesn't exist, if a row exists in those tables, it can be relied upon. But missing rows need to use a fallback to get the same data.
Synapse version N + 2
In reality, this might happen more than one Synapse version down the line to allow more time for people to upgrade and run the background update.
Bump SCHEMA_VERSION to 88 and bump SCHEMA_COMPAT_VERSION to at-least 87 because we don't want people to downgrade and miss writes while they are on an older version. Add a foreground update to finish off populating the tables completely so we can read from new tables without the fallback. Application code can now rely on the new tables being populated.
Code pointing at this issue can also be removed in this step (search the codebase for https://github.com/element-hq/synapse/issues/17623)
- The
sliding_sync_joined_rooms_to_recalculatedatabase table can be dropped - Remove the
_resolve_stale_data_in_sliding_sync_tables(...)catch-up logic and the associated tests (SlidingSyncTablesCatchUpBackgroundUpdatesTestCase) - Remove the fallback logic in the Sliding Sync API used to grab the data that we can now strictly get from the new database tables.