## Summary The `SchedulerService` for dependency management security updates enforces a `MAX_OPEN_MERGE_REQUEST_LIMIT` (currently `3`) to cap the number of auto-remediation MRs open at any given time per project. However, the current implementation only counts remediations scheduled **in the current run** via `remediation_count`. It does not account for already-open remediation MRs from previous runs. This means that if the scheduler runs multiple times, it can create up to `MAX_OPEN_MERGE_REQUEST_LIMIT` new MRs **per run**, potentially far exceeding the intended cap. ## Current Behavior In `ee/app/services/dependency_management/security_update/scheduler_service.rb`, `merge_request_limit_reached?` only checks the in-process counter: ```ruby def merge_request_limit_reached? # NOTE: This only counts remediations scheduled in the current run. # It does not account for already-open remediation MRs from previous runs. # # TODO: Add currently_open_remediation_count once MR tracking is implemented. remediation_count >= MAX_OPEN_MERGE_REQUEST_LIMIT end def currently_open_remediation_count # TODO: Implement counting of currently open remediation merge requests raise NotImplementedError end ``` ## Expected Behavior `merge_request_limit_reached?` should incorporate `currently_open_remediation_count` so the limit is enforced **across all runs**, not just within a single scheduler execution: ```ruby def merge_request_limit_reached? remediation_count + currently_open_remediation_count >= MAX_OPEN_MERGE_REQUEST_LIMIT end ``` ## Tasks - [ ] Implement MR tracking for auto-remediation merge requests (e.g. a label, a DB column, or a metadata association that identifies auto-remediation MRs) - [ ] Implement `currently_open_remediation_count` to query the number of currently open auto-remediation MRs for the project - [ ] Update `merge_request_limit_reached?` to use both `remediation_count` and `currently_open_remediation_count` - [ ] Add tests covering the cross-run limit enforcement - [ ] Consider the edge case noted in the code: if the limit is customer-configurable and is later lowered below the current open count, the strict check should not block all future runs ## Context - Introduced in !224996 (Add dependency management security update scheduler) - Related to work item https://gitlab.com/gitlab-org/gitlab/-/work_items/583114