### Summary The group milestone show page (`Groups::MilestonesController#show`) can time out because of the unbounded `COUNT(*)` query used to display the number of merge requests associated with the milestone. For large group hierarchies (e.g. root groups like `gitlab-org`), this count query is very expensive and exceeds the statement timeout. This is the merge-request twin of the already-fixed MR-list-page count issue (#563367) and a specific facet of the milestone performance meta issue (#18521). ### Steps to reproduce 1. Open the group milestone https://gitlab.com/groups/gitlab-org/-/milestones/136 2. Observe that the page currently **times out** (returns a `500`), driven by the `merge_requests` `COUNT(*)` query below. ### What is the current bug behavior? The page is slow or times out. As of filing, https://gitlab.com/groups/gitlab-org/-/milestones/136 returns a `500` (request timeout). The `COUNT(*)` for merge requests visible to the user runs across the full descendant group hierarchy with the `banned_users` anti-join and project visibility / `project_features` joins, and is unbounded. ### What is the expected correct behavior? The milestone page loads within [performance standards](https://docs.gitlab.com/ee/development/database/query_performance.html). The exact merge-request count is not essential for this view; a capped/limited count is acceptable. ### Offending query ```sql /*application:web,correlation_id:...,endpoint_id:Groups::MilestonesController#show,db_config_database:gitlabhq_production,db_config_name:main_replica*/ SELECT COUNT(*) FROM "merge_requests" INNER JOIN "projects" ON "projects"."id" = "merge_requests"."target_project_id" LEFT JOIN project_features ON projects.id = project_features.project_id WHERE (NOT EXISTS (SELECT 1 FROM "banned_users" WHERE (banned_users.user_id = (merge_requests.author_id + 0)))) AND "projects"."namespace_id" IN ( SELECT "namespaces"."id" FROM UNNEST( COALESCE( (SELECT ids FROM (SELECT "namespace_descendants"."self_and_descendant_group_ids" AS ids FROM "namespace_descendants" WHERE "namespace_descendants"."outdated_at" IS NULL AND "namespace_descendants"."namespace_id" = $3) cached_query), (SELECT ids FROM (SELECT ARRAY_AGG("namespaces"."id") AS ids FROM ( SELECT namespaces.traversal_ids[array_length(namespaces.traversal_ids, $4)] AS id FROM "namespaces" WHERE "namespaces"."type" = $5 AND (traversal_ids @> ($6))) namespaces) consistent_query)) ) AS namespaces(id) ) AND (EXISTS (SELECT $7 FROM "project_authorizations" WHERE "project_authorizations"."user_id" = $8 AND (project_authorizations.project_id = projects.id) AND (project_authorizations.access_level >= $9)) OR projects.visibility_level IN ($10, $11)) AND ("project_features"."merge_requests_access_level" IS NULL OR "project_features"."merge_requests_access_level" IN ($12, $13) OR ("project_features"."merge_requests_access_level" = $14 AND EXISTS ( SELECT $15 FROM "project_authorizations" WHERE "project_authorizations"."user_id" = $16 AND (project_authorizations.project_id = project_features.project_id) AND (project_authorizations.access_level >= $17)))) AND "merge_requests"."milestone_id" = $18 ``` ### Root cause / relevant code - Count is produced via `MilestonesController#show` → `MilestoneActions` → `Milestoneish#merge_requests_visible_to_user` (`app/models/concerns/milestoneish.rb:79`), which runs `MergeRequestsFinder` scoped to `milestone_id`. - The `NOT EXISTS (... banned_users ... merge_requests.author_id + 0)` fragment is the `MergeRequest.without_hidden` scope (`app/models/merge_request.rb:695-699`). The `+ 0` deliberately forces a nested-loop plan. ### Proposed fix Apply the same approach that resolved the MR-list-page variant in #563367: **cap/limit the count** (e.g. show `999+`) instead of executing an unbounded `COUNT(*)`, via [!216850](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/216850)-style handling. The equivalent applies to the issues count on the same page (see #505649). ### Related issues - #18521 — Meta: Milestone Performance (canonical open meta issue) - #505649 — Time to first byte on the milestone page is over 15 seconds (same endpoint; closed as duplicate of #18521; shows the `issues` count twin) - #563367 — An error occurred while getting merge request counts or listing MRs (MR-list variant; fixed by capping the count in !216850) - #574228 — Error Budget Improvement: Investigate slow requests for Project Management (lists this endpoint as a top offender) ### Suggested labels ~"type::bug" ~"bug::performance" ~"group::project management" ~"Category:Team Planning" ~"devops::plan" ~"section::dev" ~"database"