Document that background migrations must be marked

Background migrations with tracking enabled must be marked, because
this sometimes gets missed, add a review step to explicitly check
to make sure they've been marked as completed.

doc/development/background_migrations.md

@@ -410,6 +410,9 @@ the queries themselves have no timing variance.
 
 ### Background jobs tracking
 
+NOTE:
+Background migrations with job tracking enabled must call `mark_all_as_succeeded` for its batch, even if no work is needed to be done.
+
 `queue_background_migration_jobs_by_range_at_intervals` can create records for each job that is scheduled to run.
 You can enable this behavior by passing `track_jobs: true`. Each record starts with a `pending` status. Make sure that your worker updates the job status to `succeeded` by calling `Gitlab::Database::BackgroundMigrationJob.mark_all_as_succeeded` in the `perform` method of your background migration.
 

doc/development/database_review.md

@@ -250,6 +250,8 @@ Include in the MR description:
     it's suggested to treat background migrations as post migrations:
     place them in `db/post_migrate` instead of `db/migrate`. Keep in mind
     that post migrations are executed post-deployment in production.
+  - If a migration [has tracking enabled](background_migrations.md#background-jobs-tracking),
+    ensure `mark_all_as_succeeded` is called even if no work is done.
 - Check [timing guidelines for migrations](migration_style_guide.md#how-long-a-migration-should-take)
 - Check migrations are reversible and implement a `#down` method
 - Check new table migrations: