Add Gitlab::Database::BackgroundOperation::Runner
Ref: #578057 (closed)
What does this MR do and why?
This MR introduces Gitlab::Database::BackgroundOperation::Runner which adds a background job processing system for GitLab's database operations.
- A test dummy operation that can touch database records in batches for testing purposes
- Enhanced job management with new status tracking (failed, running, succeeded), retry logic for failed jobs (up to 3 attempts), and better filtering capabilities to find jobs that can be retried
-
A job execution system with two main components:
- An Executor that performs individual jobs
- A Runner that orchestrates the entire process by finding the next batch of work, creating jobs, handling failures, and determining when operations are complete
- Improved batch processing logic that can automatically stop operations if too many jobs are failing (more than 50% failure rate), handle cursor-based pagination through large datasets, and clamp batch sizes to stay within operation boundaries
- Better relationship tracking between workers and their most recent jobs
- Updated test factories to use the new dummy test operation instead of the previous migration job
The system is designed to process large database operations safely by breaking them into smaller batches, tracking progress, handling failures gracefully, and providing automatic retry mechanisms. This helps prevent database overload while ensuring operations can recover from temporary issues.
Click to expand
SingleDatabaseWorker (Cron) # Scheduler
↓ (finds migrations, queues jobs)
ExecutionWorker (Sidekiq) # Orchestrator
↓ (sets up connection, finds migration)
BatchedMigrationRunner # Runner
↓ (creates batch, orchestrates execution)
BatchedMigrationWrapper # Wrapper
↓ (executes with error handling)
Actual Migration Job Class (e.g., BackfillUserDetails)
Edited by Max Orefice