Add batched background migration to backfill security_project_tracked_context_id
What does this MR do?
This MR adds a batched background migration to backfill the security_project_tracked_context_id column for vulnerability-related tables as requested in #558135.
Background
The tables vulnerability_occurrences, vulnerability_historical_statistics, vulnerability_statistics and vulnerability_reads now have a security_project_tracked_context_id column that needs to be populated with references to the default security_project_tracked_context for each project.
Changes
Migration Logic
The migration processes projects in batches and:
-
Filters projects: Only processes projects where
project_settings.has_vulnerabilities = true -
Ensures default context exists: For each project, creates a default
security_project_tracked_contextif one doesn't exist - Backfills vulnerability tables: Updates all vulnerability-related records to reference the default tracked context
Default Context Creation
When creating a default tracked context:
- Uses the project's
default_branch(falls back to 'main' if null) - Sets
context_type = 1(branch) - Sets
is_default = true - Sets
state = 2(tracked)
Tables Updated
vulnerability_occurrencesvulnerability_readsvulnerability_statisticsvulnerability_historical_statistics
Safety Features
- Only updates records where
security_project_tracked_context_idis null - Handles race conditions when creating tracked contexts
- Uses appropriate batch sizes (1000/100) with 2-minute intervals
- Includes comprehensive test coverage
Database Impact
-
Schema:
gitlab_sec - Batch size: 1000 projects per batch, 100 per sub-batch
- Interval: 2 minutes between batches
- Tables affected: All vulnerability-related tables for projects with vulnerabilities
Testing
- Unit tests for the background migration job
- Migration spec for the queue setup
- Edge case handling (nil default_branch, existing contexts, race conditions)
Closes #558135