Security policy violations remain in "running" status indefinitely when no pipeline is created for diff_head_sha

Summary

For projects with merge request approval policies:

When a commit is pushed to a merge request that doesn't trigger a pipeline (due to workflow rules excluding the user/commit), the MR widget gets stuck showing "Checking pipeline status" and "All policy rules must be satisfied" indefinitely.

This is occurring because diff_head_pipeline is nil in this scenario. This ultimately results in the SyncFindingsToApprovalRulesWorker never being executed.

Steps to reproduce

  1. Configure a project with MR approval policies.
  2. Utilize the following .gitlab-ci.yml to disable pipelines if a specific user makes a commit.
  3. Create a new branch and push a commit.
  4. Open a merge request.
  5. Push a new commit from the user you have disabled pipelines for.
  6. Observe the MR widget stuck on "Checking if merge request can be merged" and "All policy rules must be evaluated" indefinitely
example CI config
workflow:
  rules:
    - if: $GITLAB_USER_LOGIN == "username"
      when: never
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH
    - if: $CI_COMMIT_BRANCH && $CI_OPEN_MERGE_REQUESTS
      when: never

variables:
  AST_ENABLE_MR_PIPELINES: "true"

include:
  - template: Jobs/Secret-Detection.gitlab-ci.yml

test:
  script:
    - echo ""

This can also break the bot comment. An effectively empty violation comment is present.

What is the current bug behavior?

The MR widget is stuck indefinitely "Checking if merge request can be merged" and "All policy rules must be evaluated"

What is the expected correct behavior?

I'm not sure what the best approach is here, given these changes could contain vulnerable code that lack scans in this scenario. Perhaps we should:

  • Ensure the checks are updated but failed
  • Fix the bot comment, stating that a pipeline containing required security artifacts needs to be present for the latest commit

Relevant logs and/or screenshots

Broken bot comment:

Screenshot_2026-02-11_at_11.59.55_AM

Output of checks

This bug happens on GitLab.com

Possible fixes

Patch release information for backports

If the bug fix needs to be backported in a patch release to a version under the maintenance policy, please follow the steps on the patch release runbook for GitLab engineers.

Refer to the internal "Release Information" dashboard for information about the next patch release, including the targeted versions, expected release date, and current status.

High-severity bug remediation

To remediate high-severity issues requiring an internal release for single-tenant SaaS instances, refer to the internal release process for engineers.

Edited Feb 11, 2026 by 🤖 GitLab Bot 🤖
Assignee Loading
Time tracking Loading