[reivilibre]

Part of: #11496

Follows: matrix-org/synapse#13215

These tables have been in the process of being killed off for a few years. Let's take the next step in getting rid of them, to be bundled in the same schema version bump as #20069.

This pull request is commit-by-commit review friendly.

1. Bump SCHEMA_VERSION to 95 with notes

2. Force rejected_events_metadata background update to run in foreground

3. Force events_populate_state_key_rejections background update to run in foreground

4. Stop reading from the rejections and state_events tables

5. Remove redundant RejectionsStore

Manual testing strategy

Unfortunately it's quite difficult to actually trigger this.

You need to:

• check out an old full_schema, e.g. 54 which was present when v1.62.0 was released
• remove the version 72 full_schema, as it already has the background update applied
• remove some deltas that are broken when upgrading across such a large version gap (!) It's difficult to maintain schema upgrade compatibility across large version gaps because of background updates #20070
• then run any trial test with Postgres enabled to prove that the database schema applies

git checkout v1.62.0 -- synapse/storage/schema/state/full_schemas/54                
git checkout v1.62.0 -- synapse/storage/schema/main/full_schemas/54                                                                                                
git checkout v1.62.0 -- synapse/storage/schema/common/full_schemas/54
rm -r synapse/storage/schema/*/full_schemas/72
rm synapse/storage/schema/main/delta/58/10_pushrules_enabled_delete_obsolete.sql
rm synapse/storage/schema/main/delta/79/04_mitigate_stream_ordering_update_race.py
rm synapse/storage/schema/main/delta/56/redaction_censor3_fix_update.sql.postgres
rm synapse/storage/schema/main/delta/60/01recreate_stream_ordering.sql.postgres
SYNAPSE_TEST_LOG_LEVEL=DEBUG SYNAPSE_POSTGRES=1 poetry run trial tests.handlers.test_sliding_sync.ComputeInterestedRoomsTestCase_new.test_no_joins_after_to_token

As light validation, I purposefully inserted a SQL error into the query to check that it is caught by the above testing strategy. I did this after applying this patch to ensure the background job was scheduled:

diff --git a/synapse/storage/schema/main/delta/72/03bg_populate_events_columns.py b/synapse/storage/schema/main/delta/72/03bg_populate_events_columns.py
index 3d7a77fb2d..5197a34b93 100644
--- a/synapse/storage/schema/main/delta/72/03bg_populate_events_columns.py
+++ b/synapse/storage/schema/main/delta/72/03bg_populate_events_columns.py
@@ -39,9 +39,8 @@ def run_create(cur: LoggingTransaction, database_engine: BaseDatabaseEngine) ->
     assert row is not None
     (min_stream_ordering, max_stream_ordering) = row
 
-    if min_stream_ordering is None:
-        # no rows, nothing to do.
-        return
+    min_stream_ordering = 0
+    max_stream_ordering = 42
 
     cur.execute(
         "INSERT into background_updates (ordering, update_name, progress_json)"

[github-actions]

Schema Diff

Please check that this looks as expected!

common (sqlite)

Unchanged

common (postgres)

Unchanged

main (sqlite)

Unchanged

main (postgres)

Unchanged

state (sqlite)

Unchanged

state (postgres)

Unchanged