Fix bug causing only the last schedule type policy to run
What does this MR do and why?
Fixes a bug that caused only the last schedule type scan execution policy to run.
This MR only fixes the issue for new/updated policies. Policies that were created/updated while the bug existed have had rule schedules deleted and so a migration will be needed to fix them. The migration will be created as a follow up to this MR.
Related to For "schedule" type policies, only the last sch... (#393962 - closed)
Screenshots or screen recordings
Before
Only the last policy (container scanning) runs on a scheduled basis.
After
Both policies run on a scheduled basis.
Rows in security_orchestration_policy_rule_schedules table
| id | created_at | updated_at | next_run_at | security_orchestration_policy_configuration_id | user_id | policy_index | cron | rule_index |
|---|---|---|---|---|---|---|---|---|
| 9 | 2023-03-09 00:40:05.011224 +00:00 | 2023-03-10 20:31:00.815900 +00:00 | 2023-03-10 20:45:00.000000 +00:00 | 1 | 1 | 1 | * * * * * | 0 |
| 15 | 2023-03-09 23:10:04.913272 +00:00 | 2023-03-10 20:31:01.477425 +00:00 | 2023-03-10 20:45:00.000000 +00:00 | 2 | 1 | 0 | * * * * * | 0 |
| 16 | 2023-03-09 23:10:04.944379 +00:00 | 2023-03-10 20:31:01.905164 +00:00 | 2023-03-10 20:45:00.000000 +00:00 | 2 | 1 | 1 | * * * * * | 0 |
The security_orchestration_policy_configuration with id 1 was updated before the bug was fixed, so only the last rule schedule (policy_index 1) exists. id 2 was updated after the bug was fixed, so both rule schedules exist (policy_index 0 and 1).
How to set up and validate locally
Create two scan execution policies with a schedule rule. Verify that both jobs are running periodically.
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.