Skip to content

Geo Replicables API: Add query `arguments` to the Bulk Update Mutation

Why are we doing this work

We are working to allow more robust functionality in the bulk actions in Geo and in particular allow customers to fire bulk actions on failing data: Geo: Provide a way to resync and reverify only ... (#263435 - closed)

By adding the ability to pass a query/filter to the Bulk Update Mutation it will allow us to not only fire bulk actions for failed items but for any user generated query or filtered list. This will allow us to give users even more control in regards to bulk actions.

These queries/filters should match what is available to users on the GraphQL query resolver.

Concern

From @mkozono comment

We may need to be careful to avoid letting too many of these kinds of jobs run at the same time. Actually it might be possible today to do "Resync all" and "Reverify all" at the same time for a table. It could impact performance of the Tracking DB (and if we add "Rechecksum all" to the primary site, it could impact the main or CI DB). We already prevent multiple "Resync all" jobs per table, or multiple "Reverify all" jobs per table, by relying on job deduplication.

But with a generalized "Resync by user-selected scope", it's easier to cause this problem, since the job args can vary, yet still operate on an overlapping set of rows.

We can address this by using ExclusiveLeaseGuard to prevent more than one of these kinds of jobs from operating on the same table, regardless of job args.

Forward Thinking

If we pursue the ExclusiveLeaseGuard making it known to the frontend would be important. This will allow the UI to properly disable actions when relevant.

Relevant links

Implementation plan

For the MVC, without disabling the actions (as per #520345 (comment 2379066133) below):

  1. Alongside the registry class, the RegistryBulkUpdateService needs to receive the GraphQL arguments;
  2. This allows the BaseBulkUpdateService and its children to act on those. Currently, the relation used for the bulk updates is defined in BulkMarkVerificationPendingService and BulkMarkPendingService.
  3. Once the BaseBulkUpdateService has access to the arguments, so do BulkMarkVerificationPendingService and BulkMarkPendingService. If arguments are present, the methods linked in step 2. above can be modified to only include records matching whatever arguments were passed.
  4. In order to prevent too many jobs running at the same time on the same tables, introduce an ExclusiveLeaseGuard on the bulk update. See #520345 (comment 2384235756).
Edited by Chloe Fons