### Summary Viewing a **merge request from a fork whose source project the viewer cannot read pipelines on** intermittently returns a **500** on the MR page. The failure is a `statement timeout` on a single `COUNT(*)` issued by `Ci::PipelinesForMergeRequestFinder`. This is reproducible on gitlab.com today, and reproduces on an MR whose pipeline set is **empty (0 rows)** — so it is a query-plan pathology, not a data-volume problem, and it will not age out. ### Steps to reproduce For example, opening this MR will likely timeout and get a 500 error: https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/9711 1. As a user with `read_pipeline` on a target project but **not** on the fork, open a fork MR. 2. Reload a few times — roughly 1 in 3 loads 500s. Equivalently, without loading the page: ```sh glab api "/projects/20699/merge_requests/9563/pipelines?per_page=100" ``` Observed on `gitlab-org/omnibus-gitlab`: | MR | source project readable by viewer? | timings over repeated runs | |---|---|---| | `!9711` | **no** | 6.00s, 1.56s, 1.14s, 0.78s, 0.71s, **7.55s** | | `!9563` | **no** | **15.64s (timeout)**, 1.02s, 0.75s | | `!9706`, `!9757`, `!9783`, `!9759`, `!9722` | yes | 0.58s – 0.74s | | `!9796` (same-project MR) | n/a | 0.56s – 1.03s | All 22 open fork MRs on `omnibus-gitlab` were enumerated and their source projects tested for readability. Exactly the two unreadable-source MRs spike; every readable-source fork MR and every same-project MR stays sub-second. Six consecutive runs against `!9563` returned `{"message":{"error":"Request timed out"}}` on runs 4 and 6. ### Production logs `pubsub-rails-inf-gprd-*`, correlation IDs `a3bd3879fe15e394-NRT` and `a3bd393e7d45e394-NRT` (2026-09-16 ~04:45 UTC), `Projects::MergeRequestsController#show`: | status | `duration_s` | `db_ci_replica_duration_s` | `cpu_s` | CI queries | |---|---|---|---|---| | **500** | 15.19 | 15 | 0.17 | 3 | | 200 | 11.29 | 10 | 0.87 | 31 | | **500** | 15.14 | 15 | 0.15 | 4 | `exception.class: ActiveRecord::QueryCanceled`, `exception.message: PG::QueryCanceled: ERROR: canceling statement due to statement timeout`. The whole request budget is one query; CPU is ~0.15s. The `200` is the *same* query landing at ~10.5s, just under the 15s ceiling — hence the intermittency. ### Code path ``` app/controllers/projects/merge_requests_controller.rb:116 show → :484 show_merge_request → :557 set_pipeline_variables → :559 @number_of_pipelines = @pipelines.size # COUNT(*) ``` `set_pipeline_variables` (`app/controllers/projects/merge_requests/application_controller.rb:115`) builds `@pipelines` from `Ci::PipelinesForMergeRequestFinder#execute`. ### Root cause `execute` selects the project scope **after** the union is built: ```ruby def execute if can_read_pipeline_in_target_project? && can_read_pipeline_in_source_project? all # no wrapper → fast elsif can_read_pipeline_in_source_project? all.for_project(merge_request.source_project) elsif can_read_pipeline_in_target_project? all.for_project(merge_request.target_project) # ← the slow branch else Ci::Pipeline.none end end ``` `all` → `all_pipelines_for_merge_request` → `Ci::Pipeline.from_union([...])`, which sets `FROM (<union>) p_ci_pipelines`. So `.for_project` attaches as an **outer** predicate on top of the union subquery: ```sql SELECT COUNT(*) FROM ( (SELECT "p_ci_pipelines".* FROM "p_ci_pipelines" WHERE "source" = $1 AND "merge_request_id" = $2 AND "project_id" IN ($3, $4)) UNION (SELECT "p_ci_pipelines".* FROM "p_ci_pipelines" WHERE "project_id" = $5 /* the FORK */ AND ("source" IN ($6,$7,$8,$9,$10,$11,$12,$13,$14) OR "source" IS NULL) AND "ref" = $15 AND "tag" = $16 AND "sha" = $17) ) p_ci_pipelines WHERE "p_ci_pipelines"."project_id" = $18 /* the TARGET */ ``` Four compounding problems: 1. **The second union arm is provably empty** under the outer predicate — `project_id = <fork>` ∧ `project_id = <target>` is a contradiction — yet it is still planned and executed. 2. `UNION` (dedup, not `UNION ALL`) over `SELECT *` of a wide table forces a dedup across **every column**, including `yaml_errors text`, before the outer filter can apply. 3. `p_ci_pipelines` is `PARTITION BY LIST (partition_id)` and the query carries no `partition_id`, so there is **no partition pruning** — every partition is scanned, in both arms. 4. `OR "source" IS NULL` in arm 2 (from `ci_branch_sources`) defeats the `p_ci_pipelines_project_id_source_idx` index. Note: the four factors above are read off the schema and the generated SQL, not off an `EXPLAIN` — I have no production DB access, so the precise reason the planner degrades intermittently is inferred. `EXPLAIN (ANALYZE, BUFFERS)` from Database Lab would confirm. ### Proposed fix Decide the authorized project scope **before** building the union, rather than wrapping it afterwards: - In `all_pipelines_for_merge_request`, skip the branch-pipelines arm entirely when the source project is not readable — it can never satisfy the outer filter. - Push the authorized `project_id` **inside** each arm so the predicate is available for partition pruning and index selection. `authorizing_project` (added 2026-09-01 in `3bb78f2c`) already encodes exactly this notion, but is currently wired only into `Resolvers::MergeRequestPipelinesResolver` — not into `execute`, which is what the HTML MR page uses. A cheaper mitigation, if the restructure is deferred: `@number_of_pipelines` at `merge_requests_controller.rb:559` only needs a display count, so it could be bounded (`.limit(n).size`) or moved off the synchronous page render. ### Related - #365880 — same family (`ci_branch_sources` + `OR source IS NULL` on pipelines), different endpoint. Open, `priority::4`, `workflow::blocked`.