## Summary When a vulnerability is dismissed from a Vulnerability Report the vulnerabuility report is updated, but does not schedule re-evaluation of approval policies. As a result, open merge requests with policies referencing pre-existing states remain blocked even after the blocking vulnerability is dismissed. The only way to clear the block today is to push a new commit to the source branch.. Re-running the pipeline via the UI does **not** clear the block. By contrast, when a user dismisses a finding from the MR security widget, `Security::Findings::DismissService` schedules `SyncFindingsToApprovalRulesWorker` with a 1-minute delay (added in [!206043](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/206043), shipped 18.6). The Vulnerability Report dismissal path has no equivalent. ## Steps to reproduce 1. Create a merge request approval policy that blocks on a pre-existing state, for example: ```yaml approval_policy: - name: Block pre-existing vulnerabilities enabled: true rules: - type: scan_finding scanners: - dependency_scanning vulnerabilities_allowed: 0 severity_levels: - critical - high vulnerability_states: - detected - confirmed branch_type: protected actions: - type: require_approval approvals_required: 1 ``` 2. Run a dependency scanning pipeline on the default branch that produces at least one `detected` high/critical finding. Confirm the finding appears in the project's Vulnerability Report. 3. Open a merge request against the protected branch. Observe that the MR is blocked by the approval policy. 4. Navigate to the Vulnerability Report and dismiss the finding that is triggering the block. 5. Re-run the merge request's latest pipeline via the UI (do **not** push a new commit). 6. Observe that the MR remains blocked. 7. Push any new commit to the source branch (for example, adding a newline). Observe that the MR is now unblocked. ## Current behaviour - Dismissal from the Vulnerability Report updates the `Vulnerability` record but does **not** schedule `SyncPreexistingStatesApprovalRulesWorker` for any open MR whose approval-policy violation references that vulnerability. - Re-running the pipeline does **not** re-evaluate pre-existing-states rules; only `scan_finding` newly-detected-states rules are re-evaluated by `Security::ScanResultPolicies::SyncFindingsToApprovalRulesService` on pipeline completion. - The MR remains blocked until a branch refresh occurs. ## Expected behaviour When a vulnerability is dismissed from the Vulnerability Report, GitLab should re-evaluate any approval policies whose pre-existing-states rules referenced that vulnerability, so that MRs blocked solely by the dismissed vulnerability are unblocked without requiring a branch refresh. To avoid a performance impact on bulk-dismiss operations (e.g. dismissing many findings from the Vulnerability Report at once), the enqueuing should debounce or batch per MR. ## Documentation gap The docs at [Merge request approval policies — Policy evaluation and vulnerability state changes](https://docs.gitlab.com/user/application_security/policies/merge_request_approval_policies/#policy-evaluation-and-vulnerability-state-changes) currently state: > When a user changes the status of a vulnerability (for example, dismisses the vulnerability in the vulnerability details page), GitLab does not automatically reevaluate merge request approval policies due to performance reasons. To retrieve updated data from vulnerability reports, update your merge request or rerun the related pipelines. This is misleading for policies that use pre-existing states (`detected`, `confirmed`, `dismissed`, `resolved`). Re-running the pipeline does **not** re-evaluate pre-existing-states rules — only a branch refresh does. The docs should either be made path-specific (newly-detected vs pre-existing) or, preferably, the behaviour fixed so that the docs statement holds for both paths. ## Customer impact Reported by multiple customers through GitLab Support. In each case the practical workaround has been to ask a developer to push an arbitrary commit to the source branch (for example, adding a newline) purely to trigger the branch-refresh code path. This erodes confidence in the approval policy mechanism and produces a poor UX. ## Related issues - [#560563](https://gitlab.com/gitlab-org/gitlab/-/issues/560563) — MR Approval Policy does not get re-evaluated after vulnerability state is changed (MR widget / newly-detected path, closed in %18.9 via [!206043](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/206043)). This issue is the **pre-existing-states / Vulnerability Report counterpart** to that fix. - [#362534](https://gitlab.com/gitlab-org/gitlab/-/issues/362534) — Policies still require MR approval after vulnerabilities have been dismissed (older, predates pre-existing/newly-detected split). - [#580704](https://gitlab.com/gitlab-org/gitlab/-/issues/580704) — Exclude Fixed Vulnerabilities in Merge Requests from MR Approval Blocking Policy (adjacent customer pain in the same area).