[Bug] Stuck MR security widget for child pipelines

Summary

Please see this thread for more details > gitlab-org/govern/threat-insights-demos/frontend/child-pipeline!1 (comment 2934403519)

This "parsing" loop is caused by this Feature Flag being enabled https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/models/ee/ci/pipeline.rb#L78-86

The problem is because of pipeline.can_store_security_reports? was changed to pipeline.project.can_store_security_reports?https://gitlab.com/gitlab-org/gitlab/-/blob/master/ee/app/services/security/scans/ingest_reports_service.rb#L23

This is two different things

      def can_store_security_reports?
        project.can_store_security_reports? && has_security_reports?
      end

This method on pipeline also checks if itself has_security_reports? and in our case the parent pipeline does not

Therefore set_security_mr_widget_to_ready is never set to ready in the code IngestReportsService but it previously was.

(that's why your MR works now - because the cache timed out)

Steps to reproduce

Example Project

Demo MRs - it happens in both cases:

What is the current bug behavior?

The MR security widget is stuck at loading. It uses the existing internal REST endpoint (not GraphQL).

UI Network
image image

This problem also is affecting the GraphQL endpoint. Note, the security widget is migrating to use GraphQL, which is on track to be delivered in %18.8 > MR Security widget - migrate to GraphQL (&10962)

image

GraphQL Code 
{
  project(
    fullPath: "gitlab-org/govern/threat-insights-demos/frontend/child-pipeline-ff-on"
  ) {
    mergeRequest(iid: "1") {
      findingReportsComparer(reportType:SAST) {
        status
        statusReason
        report {
          added {
            title
            uuid
            severity
            state
            aiResolutionEnabled
            foundByPipelineIid
          }
          fixed {
            title
            uuid
            severity
            state
            aiResolutionEnabled
            foundByPipelineIid
          }
        }
      }
    }
  }
}

What is the expected correct behavior?

Relevant logs and/or screenshots

Output of checks

Results of GitLab environment info

Expand for output related to GitLab environment info 

(For installations with omnibus-gitlab package run and paste the output of:
`sudo gitlab-rake gitlab:env:info`)

(For installations from source run and paste the output of:
`sudo -u git -H bundle exec rake gitlab:env:info RAILS_ENV=production`)

Results of GitLab application Check

Expand for output related to the GitLab application check 
(For installations with omnibus-gitlab package run and paste the output of:
sudo gitlab-rake gitlab:check SANITIZE=true)


(For installations from source run and paste the output of:
sudo -u git -H bundle exec rake gitlab:check RAILS_ENV=production SANITIZE=true)


(we will only investigate if the tests are passing)

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 by Samantha Ming