I tend to agree that that this “heavy migration” more-than-likely requires additional review and stringent development testing on a test configuration with a large DB before merged into core. Lucky for our site, I always bootstrap in parallel to production so we did not suffer any downtime during the migration failure(s), so no worries on our end. Thanks for reverting so quickly.
FYI only (just being technically precise, sorry about that… ), I checked the DB after rebuilding just now and the “revert” process did not drop the table from DB, no big deal, just FYI only:
discourse=> \d dismissed_topic_users
Table "public.dismissed_topic_users"
Column | Type | Collation | Nullable | Default
------------+-----------------------------+-----------+----------+---------------------------------------------------
id | bigint | | not null | nextval('dismissed_topic_users_id_seq'::regclass)
user_id | integer | | |
topic_id | integer | | |
created_at | timestamp without time zone | | |
Indexes:
"dismissed_topic_users_pkey" PRIMARY KEY, btree (id)
"index_dismissed_topic_users_on_user_id_and_topic_id" UNIQUE, btree (user_id, topic_id)
Thank you again for your hard work on this and for quickly reverting the migration.
