From checking the psql table:
gitlabhq_production=# select * from background_migration_jobs;
id | created_at | updated_at | status | class_name
| arguments
----+-------------------------------+-------------------------------+--------+-----------------------------------------------------
---------------------+-----------------------------------------------------------------
1 | 2020-09-11 07:53:56.948512+00 | 2020-09-11 07:56:02.755423+00 | 1 | Gitlab::Database::PartitioningMigrationHelpers::Back
fillPartitionedTable | [1, 1706, "audit_events", "audit_events_part_5fc467ac26", "id"]
4 | 2021-05-24 12:31:10.668441+00 | 2021-05-24 12:33:12.410308+00 | 1 | BackfillNamespaceTraversalIdsRoots
| [1, 31, 100]
5 | 2021-07-22 20:29:05.751912+00 | 2021-07-22 20:31:11.180535+00 | 1 | MigrateMergeRequestDiffCommitUsers
| [1, 40001]
10 | 2022-01-24 11:42:26.819665+00 | 2022-01-24 11:44:29.253568+00 | 1 | BackfillIncidentIssueEscalationStatuses
| [46, 1786]
12 | 2022-03-22 21:32:38.517548+00 | 2022-03-22 21:32:38.517548+00 | 0 | ResetDuplicateCiRunnersTokenValuesOnProjects
| [2, 9]
11 | 2022-03-22 21:32:38.315361+00 | 2022-03-22 21:34:47.424816+00 | 1 | ResetDuplicateCiRunnersTokenEncryptedValuesOnProject
s | [2, 18]
(6 rows)
I guess potentially I could manually change the status from 0 to 1. But would prefer a cleaner method if possible.
If anyone has any ideas, would be great, but am still curious how it can be pending, and yet show as completed (up).