Size GLQL aggregated pages from the backend page cap

What does this MR do and why?

This MR is stacked on the backend MR !257575 (merged): it targets the backend branch aggregation-engine-page-size-250 and should merge after that MR merges.

GLQL auto-paginates aggregated displays (charts, stats, bar lists, heat maps) in analytics mode. It fetches page after page, up to 1000 rows, before rendering. The page size was hard-coded as AGGREGATED_AUTO_PAGE_SIZE = 100 in app/assets/javascripts/glql/constants.js. The backend MR raises the ClickHouse aggregation engine's page cap to 250, so this MR reads that value instead of hard-coding 100.

• The backend now exposes the ClickHouse aggregation engine cap as gon.aggregation_max_page_size (set in lib/gitlab/gon_helper.rb from Gitlab::Database::Aggregation::ClickHouse::Engine.max_page_size), so the value lives in one place on the backend. It is only set while the backend's larger_clickhouse_aggregation_pages flag is enabled for the current user, so GLQL keeps 100-row pages whenever the backend does.
• app/assets/javascripts/glql/components/common/resolver.vue gets a computed aggregatedPageSize that reads gon.aggregation_max_page_size, falling back to the old value of 100 when gon lacks it.
• That computed value is used in three places: the limit variable for auto-paginated queries, the request cap (maxPages = ceil(1000 / pageSize), so 4 requests at 250 instead of 10 at 100), and the check that drops the trend comparison once the main result spans more than one page. The comparison now stays valid up to 250 rows instead of 100.

Only analytics-mode queries use auto pagination, and every analytics source is a ClickHouse aggregation engine, so non-aggregated queries (issues, work items, lists, tables) are unaffected and keep their own page sizes. Effect: a chart with 1000 aggregated rows now takes 4 requests instead of 10, so the full ClickHouse aggregation runs 4 times instead of 10.

References

https://gitlab.com/gitlab-org/gitlab/-/work_items/630507, item "Bigger aggregation pages".

Depends on: !257575 (merged)

Screenshots or screen recordings

Not applicable, this MR has no UI change.

How to set up and validate locally

1. Check out this branch with GDK running, enable the flag in bin/rails console with Feature.enable(:larger_clickhouse_aggregation_pages), and have ClickHouse data, for example the DAP Impact dashboard under Explore > Analytics dashboards.
2. Open the browser network tab filtered to glql.
3. Load a chart panel with more than 100 aggregated rows. You should see requests with limit: 250 and fewer continuation requests.
4. In the browser console, gon.aggregation_max_page_size returns 250. With the flag disabled it is undefined and requests use limit: 100.

New Jest cases in spec/frontend/glql/components/common/resolver_spec.js cover pages of 250 requested and capped at 4 requests, and the comparison kept at a count of 250. Both fail without this change. New cases in spec/lib/gitlab/gon_helper_spec.rb cover the gon value with the flag on and off.

MR acceptance checklist

Evaluate this MR against the MR acceptance checklist. It helps you analyze changes to reduce risks in quality, performance, reliability, security, and maintainability.

🤖 Generated with Claude Code