Split operations in processScanResultWorker into multiple workers
What does this MR do and why?
Moves SyncOpenedMergeRequestsService
call from ProcessScanResultPolicyWorker
to its own worker.
We are spliting the operations performed in ProcessScanResultPolicyWorker
into multiple workers and make it loosely coupled or eventually consistent in #393871 (closed) as discussed in this proposal
Also as discussed, if there is a race when the worker runs for a config rule which is already deleted, it would be harmless.
I also observed during the development process that in Postgres updating a row(s) which does not exist is harmless i.e there are no errors raised. The affected rows alone is returned to the internal rails connection object and the rows that does not exist is not included to affected row(s) count. So I think we need not catch AR errors and let the worker run as is and finish, we can roll this out with a FF as planned.
Related to #407761 (closed)
How to set up and validate locally
- Create a Simple scan result policy like this example.
- Enable the FF in rails console
Feature.enable(:sync_mr_approval_rules_security_policies)
- Create a new protected branch which invokes Security::ProcessScanResultPolicyWorker and in the log/sidekiq.log, we should observe the new worker with
job_status: start
andjob_status: done
.
MR acceptance checklist
This checklist encourages us to confirm any changes have been analyzed to reduce risks in quality, performance, reliability, security, and maintainability.
-
I have evaluated the MR acceptance checklist for this MR.
Related to #407761 (closed)