## Problem The MR Pipelines tab (`pipelines_table_wrapper.vue`, behind `mr_pipelines_graphql`) opens one `ciPipelineStatusUpdated` subscription per pipeline, but only for pipelines with status in `PIPELINE_ALIVE_STATUSES`. This leaves finished pipelines untracked. Finished pipelines change when: - A job is retried - A manual job runs - A pipeline is canceled or deleted The client cannot predict which rows will change. To cover these cases, the wrapper keeps `forcedAliveParentIds` and `forcedAliveDownstreamIds`. It depends on bootstrap events (`job-action-executed` from `job_action_button.vue`, `retried` from the failed jobs widget) to learn an action happened, then refetches. These events are emitted after the mutation resolves, from components that a subscription payload can destroy first. Vue 2 `$destroy` calls `$off()`, so the emit is lost. The row stays stale until the 60 s poll. MR !253179 works around one instance with `provide`/`inject`. Downstream pipelines use separate bookkeeping (`aliveDownstreamIds`, `MAX_DOWNSTREAM_SUBSCRIPTIONS`) with the same weakness. ## Proposal Principle: the subscription set is a pure function of what is rendered, scoped like the list query. 1. One subscription per list, keyed by merge request: `ciPipelineStatusesUpdated(mergeRequestId:)`. This argument shape does not exist yet. Existing shapes are `projectId`, `projectFullPath`, and both combined with `sha`. `sha` does not cover an MR, because merged-results and merge-train pipelines run on a different sha than the source branch. Each argument set is its own topic, so add a trigger call in `GraphqlTriggers.ci_pipeline_statuses_updated` and an argument in `Subscriptions::Ci::Pipelines::StatusesUpdated`. 2. Payload equals the row fragment (`MergeRequestPipelineListItem`). Apollo normalizes it into the cached `Pipeline` entity. `updateQuery` stays a pass-through, as the wrapper does today. 3. A payload for a pipeline id not in the current page means a new pipeline. Refetch the list query. 4. Downstreams ride the same channel. Trigger the MR-scoped topic for child pipelines whose parent belongs to the MR. The payload normalizes into the entity the `downstreamPipelines` query references. A new downstream is an unknown id, which refetches. 5. Detail subscriptions follow visibility. An expanded failed jobs widget or an open stage dropdown subscribes to its own narrow document while mounted and unsubscribes on unmount. MR !253179 already does this for the widget. 6. Actions are fire-and-forget mutations. Remove `job-action-executed` and `retried` as sync signals. Remove `forcedAliveParentIds`, `forcedAliveDownstreamIds`, `aliveParentIds`, `aliveDownstreamIds`, and `MAX_DOWNSTREAM_SUBSCRIPTIONS`. Success UX such as a toast is shown by the component that ran the mutation. 7. Keep the 60 s poll only as the fallback for blocked websockets. ## Implementation steps - Backend: add `merge_request_id` argument to `Subscriptions::Ci::Pipelines::StatusesUpdated`. Authorize `read_pipeline` on the MR's project. Add the trigger call for `{ merge_request_id: pipeline.merge_request.to_gid }` when `pipeline.merge_request_id` is present, and for child pipelines whose parent has an MR. Respect the existing per-project rate limit. Add specs. - Frontend: replace the per-pipeline subscriptions and downstream subscriptions in the wrapper with the one MR-scoped subscription. Add unknown-id refetch. Delete alive bookkeeping and bootstrap events. Update `pipelines_table.vue`, `job_action_button.vue`, `job_dropdown_item.vue`, `pipeline_stage_dropdown.vue`, and `pipeline_failed_jobs_widget.vue` accordingly. Add Jest specs. - Verify with feature specs on the MR Pipelines tab: retry from stage dropdown, retry from widget, manual bridge job creating a downstream, new pipeline pushed while the tab is open, websockets blocked. ## Cost A trigger is one publish per topic. The per-subscriber cost is a GraphQL execution on an ActionCable thread. With one list subscription per tab, this scales with open tabs, not rows. This is cheaper than up to 20 per-pipeline subscriptions on a busy MR, and much cheaper than the former 10 s poll. The BatchLoader executor reset added in MR !253179 (`lib/gitlab/graphql/subscriptions/action_cable_with_load_balancing.rb`) is required, since one thread serves many payloads. ## Out of scope - The pipeline details page, which keeps `ciPipelineStatusUpdated(pipelineId:)`. - The REST path (`mr_pipelines_graphql` disabled). - MR !253179 itself, which should land first with the `job-action-initiated` reorder. ## References - Follow-up to https://gitlab.com/gitlab-org/gitlab/-/merge_requests/253179, where the alive-only subscription model forced a `provide`/`inject` workaround - Bug that surfaced the problem: https://gitlab.com/gitlab-org/gitlab/-/work_items/606907 - Existing `projectFullPath` argument shape for `ciPipelineStatusesUpdated`: https://gitlab.com/gitlab-org/gitlab/-/merge_requests/243802 <!-- claude session=dfc23a78-cd04-4bd9-aa0b-f0032afbc705 posted=2026-09-08T05:17:50Z -->