Check for nil values before adding constrains to the DB tables
Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.
Proposal
Time and time again when customers are upgrading to newer version of GitLab facing issues when we add constrains for database tables and migrations fail due to table records not meeting these constrains. This blocks production upgrades and causes downtimes forcing customers to roll back. There must be a better way to handle these, maybe check the records in the table before trying to add the constrain and if they don't pass the constrain more gracefully handle the failure not blocking the upgrade? Or do some pre-checks before upgrade.
Example below:
Customer upgraded from 17.8.7-ee.0 to 17.11.2-ee.0. There was a migration AddVulnerabilityUserMentionsProjectIdNotNullConstraint adding a null constrain to the vulnerability_user_mentions table for the project_id. Because the table vulnerability_user_mentions had records with project_id as null the rest of the migrations failed forcing customer to roll back to 17.8.7-ee.0. I've seen this happen numerous times for other tables/customers.
I guess these should have been backfilled with the background migration !155289 (merged)