### Summary The merge request security widget polls `enabledSecurityScans.ready` every 3 seconds. The poll has no maximum interval, no attempt limit, and no deadline. It stops only when `ready` becomes `true`. A successful response with `ready: false` has no terminal handling, so the UI shows "Security scanning is loading" for as long as the page stays open. So any cause that leaves `ready` false produces a loading state that does not end. These causes are known: - An SBOM without dependency scanning attributes (#568889). Fixed in 18.5. - A head pipeline in `blocked` status (#580889). Open, no milestone. - A blocking manual job in a stage before the scan job, so the scan job stays in `created`. Reproduced on GitLab.com for this report (steps below). - Partial finding ingestion: a security report artifact exists, but no `Security::Scan` row exists for it. Observed on a GitLab Dedicated tenant, where `ready` was still false 44 hours after the pipeline passed. Not reproduced on GitLab.com. Each cause is a separate issue and needs its own fix. This work-item covers only the shared frontend behaviour: the poll has no bound, so each cause becomes the same state. That state does not recover, and it does not show the cause to the user. Two frontend paths are affected: - `ee/app/assets/javascripts/vue_merge_request_widget/widgets/security_reports/` (Overview tab). This path has a CODEOWNERS entry. - `ee/app/assets/javascripts/merge_requests/reports/security_scans/` (Reports tab). This path has no CODEOWNERS entry. In the Reports tab provider, one file has two pollers. The per-report poller has `maxInterval` and a growth factor. The readiness poller has neither. ### Steps to reproduce ~Ultimate required. 1. Create a project with container scanning enabled. 2. On a branch, add this `.gitlab-ci.yml`. It puts a blocking manual job in a stage before the scan job: ```yaml stages: - gate - test include: - template: Jobs/Container-Scanning.gitlab-ci.yml container_scanning: stage: test variables: CS_IMAGE: node:10.6-alpine gate: stage: gate script: - echo "blocking manual gate" when: manual allow_failure: false ``` 3. Open a merge request from that branch. 4. Let the pipeline settle. Do not run `gate`. The pipeline reports status `manual` and `active: false`, and `container_scanning` stays in `created`. 5. Query readiness: ```graphql { project(fullPath: "<PATH>") { pipeline(iid: "<IID>") { status active enabledSecurityScans { ready } } } } ``` The query returns `{"status":"MANUAL","active":false,"ready":false}` on every call. 6. Open the merge request **Overview** tab. The security widget shows the loading state without completing. 7. Open the **Reports** tab. "Security scan" shows the same loading state, with an empty report area. Measured on GitLab.com on 2026-09-27: `ready` was false at t+0, t+60 seconds, and t+4 minutes. The widget still showed the loading state after 2 minutes of observation. ### What is the current _bug_ behavior? `ready` stays false, and the UI polls with no end. All line references are pinned to commit `6e6eb03999fede4f79da8e7d49c2b3b37e636240`. **Overview widget:** [`mr_widget_security_reports.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/vue_merge_request_widget/widgets/security_reports/mr_widget_security_reports.vue) The poller has no bound ([L271-278](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/vue_merge_request_widget/widgets/security_reports/mr_widget_security_reports.vue#L271-278)): ```js initPolling() { this.$options.pollingInterval = new SmartInterval({ callback: () => this.$apollo.queries.enabledScans.refetch(), startingInterval: POLL_INTERVAL, // 3000, L33 incrementByFactorOf: 1, immediateExecution: true, }); } ``` - `maxInterval` is not set, and `incrementByFactorOf: 1` keeps the interval at 3 seconds. - The component starts the poller when `ready` is not true, and destroys it only when `ready` is true ([L233-240](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/vue_merge_request_widget/widgets/security_reports/mr_widget_security_reports.vue#L233-240)). - `isLoadingEnabledScans` is truthy while the poller object exists, not only while a request is in flight ([L206-208](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/vue_merge_request_widget/widgets/security_reports/mr_widget_security_reports.vue#L206-208)). - While `isLoadingEnabledScans` is truthy, `shouldRenderMrWidget` is false ([L198-204](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/vue_merge_request_widget/widgets/security_reports/mr_widget_security_reports.vue#L198-204)). The template then mounts a placeholder loading widget instead of the real widget ([L521-532](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/vue_merge_request_widget/widgets/security_reports/mr_widget_security_reports.vue#L521-532)). - The template comment gives the reason for the placeholder ([L512-520](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/vue_merge_request_widget/widgets/security_reports/mr_widget_security_reports.vue#L512-520)): the real widget calls `fetchCollapsedData` on mount, and that call needs the enabled scans. - `error()` handles failed requests only ([L249-253](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/vue_merge_request_widget/widgets/security_reports/mr_widget_security_reports.vue#L249-253)). An HTTP 200 response with `ready: false` has no handling. **Reports tab:** [`security_scans_provider.vue`](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/merge_requests/reports/security_scans/security_scans_provider.vue) One file has two pollers: | | Readiness poller | Per-report poller | |--|------------------|-------------------| | Location | [L280-287](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/merge_requests/reports/security_scans/security_scans_provider.vue#L280-287) | [L382-388](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/merge_requests/reports/security_scans/security_scans_provider.vue#L382-388) | | `startingInterval` | `POLL_INTERVAL` (3000) | `POLL_INTERVAL` (3000) | | `maxInterval` | not set | `MAX_POLL_INTERVAL` (30000) | | `incrementByFactorOf` | 1 | 1.5 | Both constants are declared together ([L24-25](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/merge_requests/reports/security_scans/security_scans_provider.vue#L24-25)). Inference from the code: backoff was applied to the per-report poller and not to the readiness poller. I have not checked the history for a reason. - The component starts and destroys the readiness poller on the same single condition ([L107-114](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/merge_requests/reports/security_scans/security_scans_provider.vue#L107-114)). - `isLoading` is truthy while the poller object exists (`Boolean(this.pollingInterval)`, [L160-172](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/merge_requests/reports/security_scans/security_scans_provider.vue#L160-172)). - `isLoading` is also truthy while `hasEnabledScans` is true and `reports` is empty ([L169](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/merge_requests/reports/security_scans/security_scans_provider.vue#L169)). - The component fetches finding reports only when `ready` is true ([L118-120](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/ee/app/assets/javascripts/merge_requests/reports/security_scans/security_scans_provider.vue#L118-120)). So while `ready` is false, the L169 condition stays true even if the poller is destroyed. **SmartInterval has no attempt limit:** [`smart_interval.js`](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/app/assets/javascripts/smart_interval.js) This limits the fix. `maxInterval` limits the interval length. It does not limit the number of attempts or the elapsed time ([L79-91](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/app/assets/javascripts/smart_interval.js#L79-91), [L188-199](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/app/assets/javascripts/smart_interval.js#L188-199)). When `maxInterval` is undefined, `getCurrentInterval() === cfg.maxInterval` is never true and `nextInterval > cfg.maxInterval` never clamps. So the readiness poller runs every 3 seconds with no end. The per-report poller also runs with no end, but every 30 seconds instead of every 3. A `maxInterval` alone does not bound a poll. **Secondary cost (reported by a customer, not reproduced).** The spinner uses a CSS animation (`.gl-animate-spin { animation: gl-spin 0.6s infinite linear; }`). A customer measured about 50% use of an integrated GPU while a merge request page was open. We have not reproduced this measurement. Inference: the cost follows from the loading state having no end, because the animation runs for as long as the spinner renders. ### What is the expected _correct_ behavior? In order of value: 1. The readiness poll must stop after a deadline or an attempt limit. 2. When the poll stops, the UI must show a terminal state that names the scans that have not reported. #580889 asks for the same thing: "Maybe a message like 'waiting for pipeline to complete' would be more helpful to the user." 3. Reports that have resolved should render while readiness is unresolved. On the customer's merge request, License Compliance and Code Quality resolved on the same page load, and the security scan did not. So the data for partial results was present. Any change here must keep the constraint at L512-520: the real widget needs the enabled scans before it mounts. A user must be able to tell "scanning is in progress" from "scanning finished and something else is wrong". Today both states look the same on screen, and the second state does not end. ### Relevant logs and/or screenshots From a customer HAR, captured on GitLab Dedicated on 2026-09-20, for one merge request page ([ZD](https://gitlab.zendesk.com/agent/tickets/683110) - Internal): - 12 `enabledScans` requests in 30 seconds, each HTTP 200 with `"ready": false`. The first two requests were sent together (the initial query, then the `immediateExecution` refetch), then one every 3 seconds. This pattern matches the poller configuration at L271-278. - `headPipeline.updatedAt` was 44 hours before the capture. The pipeline had passed, with `active: false`. - On the same page load, `license_scanning_reports` returned 204, 204, then 200. License Compliance and Code Quality rendered. Only the security scan did not. A screenshot of the same merge request shows the Reports tab with "Security scan" selected, an empty report area, and "Security scanning is loading". License compliance shows a success indicator, and Code quality shows a warning indicator. **Difference from #628004.** #628004 (filed 2026-09-08) describes the customer symptom as `security_reports` returning HTTP 204 indefinitely. That description came from the customer report, before this HAR was captured on 2026-09-20. The evidence now shows a different mechanism: - HAR: every `enabledScans` response is HTTP 200 with `ready: false`. - HAR: the 204 responses recorded are from `license_scanning_reports`, and that endpoint reached 200. - Code: the frontend does not request security finding reports while `ready` is false (provider L118-120, widget L512-520). Inference: on this page load, the loading state comes from the readiness poll, not from a security report endpoint that returns 204. The HAR does not show which endpoint the earlier description referred to. ### Output of checks This bug happens on GitLab.com. ### Possible fixes 1. Give the readiness poller a deadline or an attempt limit. SmartInterval has neither, so this needs a small addition to SmartInterval (an optional `maxAttempts` or deadline) or a counter in the two components. The component change is smaller. 2. Add `maxInterval` and a growth factor above 1 to the readiness poller, to match the per-report poller. With `incrementByFactorOf: 1`, `maxInterval` has no effect, because the interval never grows. This change reduces load, but it does not bound the poll. 3. Add a terminal branch for `ready: false` after the deadline, next to the existing `error()` handler. Show the scans that have not reported. 4. Base the loading state on request state, not on the poller object. Two places must change: - `isLoadingEnabledScans` (widget L206-208) and `Boolean(this.pollingInterval)` in `isLoading` (provider L160-172). These stay truthy while SmartInterval has cancelled its timer on `blur` or hidden visibility ([L95-107](https://gitlab.com/gitlab-org/gitlab/-/blob/6e6eb03999fede4f79da8e7d49c2b3b37e636240/app/assets/javascripts/smart_interval.js#L95-107)). This is why the loading state continues while no requests are sent. - `this.hasEnabledScans && this.reports.length === 0` (provider L169). This condition stays true while `ready` is false, even after the poller stops. If only the first place changes, the Reports tab still shows the loading state. ### Related issues - #580889: same symptom, with a head pipeline in `blocked` status. Its published steps put the manual job after the scan job. On GitLab.com today, that configuration returns `ready: true`. - #568889: same symptom, from an SBOM without dependency scanning attributes. Fixed in 18.5, so a widget that loads with no end has been treated as a defect before. - #557787: feature request to keep findings after the report artifact expires. Related, but not a fix path for this issue. - #628004: a separate SAST template retention defect, found while investigating the same customer report. See the difference noted above.