### Summary The group roadmap fetches milestones for the group, its ancestors and its descendants in one unpaginated GraphQL request, so it receives only the 100 due earliest and gives no notice of the rest. A subgroup whose ancestors have more than 100 active milestones due before its own sees none of its own on "This year". ### Steps to reproduce 1. In a Premium or Ultimate top-level group, create a subgroup. 2. In the top-level group, create 100 active milestones with dates between January and April of this year. 3. In the subgroup, create one milestone with dates in December, and an epic with start and due dates this year. 4. Open the subgroup's roadmap with `?layout=MONTHS&timeframe_range_type=CURRENT_YEAR&show_milestones=true`. 5. Close one of the top-level group's milestones and reload. ### Example Project The public group [the-foundry](https://gitlab.com/groups/gitlab-com/public-sector/exhibits/the-foundry) has three active milestones of its own, Heat 4, 5 and 6, due between October 2026 and January 2027. - [This year](https://gitlab.com/groups/gitlab-com/public-sector/exhibits/the-foundry/-/roadmap?layout=MONTHS&timeframe_range_type=CURRENT_YEAR&show_milestones=true): 100 milestones from its ancestor `gitlab-com`, no Heats. - [This quarter](https://gitlab.com/groups/gitlab-com/public-sector/exhibits/the-foundry/-/roadmap?layout=WEEKS&timeframe_range_type=CURRENT_QUARTER&show_milestones=true): the group's own milestones appear. ### What is the current *bug* behavior? At step 4 the roadmap's milestones request returns 100 of the top-level group's milestones and not the subgroup's. After step 5 it includes the subgroup's, and so does moving that milestone's due date ahead of the others. Workarounds: a shorter range such as "This quarter", or fewer active milestones in ancestor groups. ### What is the expected *correct* behavior? The roadmap shows every active milestone in the selected range, as its documentation describes ([`doc/user/group/roadmap/_index.md:167-169`](https://gitlab.com/gitlab-org/gitlab/-/blob/08d719a38f0b12f48038ce7cd6e4dd5ed67f3d9c/doc/user/group/roadmap/_index.md?plain=1#L167-169)). ### Relevant logs and/or screenshots With "This year", the example page sends one `groupMilestonesEE` request with these variables and receives 100 nodes. Adding `after` and `pageInfo` to the same query returns the Heats on page 2. ```json {"fullPath":"gitlab-com/public-sector/exhibits/the-foundry","state":"active","timeframe":{"start":"2026-01-01","end":"2026-12-31"},"includeDescendants":true,"includeAncestors":true} ``` #### Failing path ```mermaid flowchart TD A["Roadmap on a subgroup<br/>range: This year"] --> B["roadmap_shell.vue variables()<br/>state active, timeframe<br/>includeAncestors, includeDescendants<br/>no first, no after"] B --> C["groupMilestonesEE<br/>one request, no pageInfo selected"] C --> D["GroupMilestonesResolver<br/>group, ancestors and descendants<br/>sort due_date_asc"] D --> E{"GitlabSchema<br/>default_max_page_size 100"} E -->|"first 100 by due date"| F["update() keeps nodes"] E -.->|"101st onward"| X["never requested"] F --> G["milestonesToShow<br/>filters in the browser"] G -->|"Show all or group milestones"| H["ancestor milestones only"] G -->|"Show sub-group milestones"| I["none of the subgroup's own<br/>no notice"] ``` ### Output of checks This bug happens on GitLab.com (19.5.0-pre, revision 4ceeb1e8524). ### Possible fixes The lines responsible are the query in [`group_milestones.query.graphql`](https://gitlab.com/gitlab-org/gitlab/-/blob/08d719a38f0b12f48038ce7cd6e4dd5ed67f3d9c/ee/app/assets/javascripts/roadmap/queries/group_milestones.query.graphql), the Apollo block in [`roadmap_shell.vue:53-73`](https://gitlab.com/gitlab-org/gitlab/-/blob/08d719a38f0b12f48038ce7cd6e4dd5ed67f3d9c/ee/app/assets/javascripts/roadmap/components/roadmap_shell.vue#L53-73) that reads only `nodes`, and `default_max_page_size 100` in [`gitlab_schema.rb:33`](https://gitlab.com/gitlab-org/gitlab/-/blob/08d719a38f0b12f48038ce7cd6e4dd5ed67f3d9c/app/graphql/gitlab_schema.rb#L33), which applies when `first` is omitted and also caps a larger `first`. The resolver sorts by due date by default ([`milestones_resolver.rb:33-36`](https://gitlab.com/gitlab-org/gitlab/-/blob/08d719a38f0b12f48038ce7cd6e4dd5ed67f3d9c/app/graphql/resolvers/milestones_resolver.rb#L33-36)). The epics query on the same page already pages, first added in !65652 ([`roadmap_app.vue:102-107`](https://gitlab.com/gitlab-org/gitlab/-/blob/08d719a38f0b12f48038ce7cd6e4dd5ed67f3d9c/ee/app/assets/javascripts/roadmap/components/roadmap_app.vue#L102-107), [`:174-192`](https://gitlab.com/gitlab-org/gitlab/-/blob/08d719a38f0b12f48038ce7cd6e4dd5ed67f3d9c/ee/app/assets/javascripts/roadmap/components/roadmap_app.vue#L174-192), [`graphql.js:34-59`](https://gitlab.com/gitlab-org/gitlab/-/blob/08d719a38f0b12f48038ce7cd6e4dd5ed67f3d9c/ee/app/assets/javascripts/roadmap/graphql.js#L34-59)). Milestones could page the same way, fetching every page with a request cap as the frontend GraphQL guide recommends for loading all data up front ([`fe_guide/graphql.md:1104-1170`](https://gitlab.com/gitlab-org/gitlab/-/blob/08d719a38f0b12f48038ce7cd6e4dd5ed67f3d9c/doc/development/fe_guide/graphql.md?plain=1#L1104-1170)). When !149082 moved this fetch out of Vuex, a reviewer [asked](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/149082#note_1857473822) whether the unpaginated fetch had caused trouble with many nodes, and the change kept it unpaginated for consistency. With every page fetched, "Show all milestones" would list every ancestor milestone in range. Which milestones to show is the subject of #426620 and gitlab-org&10937. Would the group be open to me attempting the fix under its guidance, paging the milestones query the way the epics query already pages? ### Patch release information for backports If the bug fix needs to be backported in a [patch release](https://handbook.gitlab.com/handbook/engineering/releases/patch-releases) to a version under [the maintenance policy](https://docs.gitlab.com/policy/maintenance/), please follow the steps on the [patch release runbook for GitLab engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/patch/engineers.md). Refer to the [internal "Release Information" dashboard](https://dashboards.gitlab.net/d/delivery-release_info/delivery3a-release-information?orgId=1) 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](https://handbook.gitlab.com/handbook/engineering/releases/internal-releases/) for single-tenant SaaS instances, refer to the [internal release process for engineers](https://gitlab.com/gitlab-org/release/docs/-/blob/master/general/internal-releases/engineers.md?ref_type=heads).