Add migration step to safeguard rename config_version migration
Issue: Backend: Rename config_version field to desired... (#479693 - closed)
What does this MR do and why?
Related to: Rename config_version field to desired_config_g... (!165876 - merged)
Why this is needed? This MR is needed because we had some cases where the migration failed due to the config_version field missing in the database (reason unknown)
See !165876 (comment 2143316494) for more details
So we decided to add an additional step to the migration as a safeguard to ensure that the migration succeeds and the database is left in a consistent state after the migration.
What it does?
Adds a migration step for adding config_version
field to migration version 20240925194439
before execution of the rename_column_concurrently
step
MR acceptance checklist
Please evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.
Screenshots or screen recordings
No UI Changes
How to set up and validate locally
To validate you can rollback the relevant migrations, drop the config_version
field (destructive operation data will be lost) to reproduce the issue of missing column and migrate again
-
bundle exec rails db:migrate:down:main VERSION=20240925194509
-
bundle exec rails db:migrate:down:ci VERSION=20240925194509
-
bundle exec rails db:migrate:down:main VERSION=20240925194439
-
bundle exec rails db:migrate:down:ci VERSION=20240925194439
-
bundle exec rails db
-
ALTER TABLE workspaces DROP COLUMN config_version;
-
bundle exec rails db:migrate
Finally check that the migration succeeds and the new desired_config_generator_version
column exists in the database