Skip to content

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

  1. bundle exec rails db:migrate:down:main VERSION=20240925194509

  2. bundle exec rails db:migrate:down:ci VERSION=20240925194509

  3. bundle exec rails db:migrate:down:main VERSION=20240925194439

  4. bundle exec rails db:migrate:down:ci VERSION=20240925194439

  5. bundle exec rails db

  6. ALTER TABLE workspaces DROP COLUMN config_version;

  7. bundle exec rails db:migrate

Finally check that the migration succeeds and the new desired_config_generator_version column exists in the database

Edited by Daniyal Arshad

Merge request reports

Loading