Give dashboard GLQL panels their own request queue

What does this MR do and why?

Every GLQL request in the browser went through one static TaskQueue with a concurrency of 1 in app/assets/javascripts/glql/core/executor.js. That queue was shared by GLQL blocks embedded in issue and MR descriptions and comments (rendered via facade.vue) and by GLQL panels on analytics dashboards (rendered via app/assets/javascripts/analytics/analytics_dashboards/components/visualizations/glql.vue). Dashboard panels loaded strictly one request at a time. The DAP Impact system dashboard has 42 GLQL panels, 15 of which also run a trend comparison query, so it issued 57 requests serially. Every other dashboard data source already fetches its panels in parallel; GLQL panels were the only ones serialized.

The executor now keeps named queues instead of one static queue. EXECUTION_QUEUE_DEFAULT (glql-queue-default) keeps a concurrency of 1 and is what every caller gets unless it asks otherwise. EXECUTION_QUEUE_DASHBOARD (glql-queue-dashboard) has a concurrency of 4. GlqlResolver (app/assets/javascripts/glql/components/common/resolver.vue) gains a queue prop, defaulting to EXECUTION_QUEUE_DEFAULT, and passes it on every request it makes: the main query, the comparison query, and load-more pages. The dashboard visualization binds :queue="$options.EXECUTION_QUEUE_DASHBOARD", so panels on one dashboard share that one queue and at most 4 GLQL requests are in flight per dashboard. Any name the executor does not recognize falls back to the default queue rather than starting a queue of its own. Pages within a single chart stay sequential because each page needs the previous cursor; the parallelism is across panels, not within one. The linked work item measured that four charts of 566 rows each, at 6 sequential pages of 3 to 5 seconds, take 80 to 100 seconds serialized at concurrency 1 and about 25 seconds at concurrency 4, and proposed 3 or 4; this MR uses 4.

The limit of 1 was never a technical limit. It was a production-readiness commitment made for the GLQL beta in GitLab 17.9, introduced in !180921 (merged) after the readiness review at https://gitlab.com/gitlab-org/gitlab/-/issues/517546 (readiness MR gitlab-com/gl-infra/readiness!224 (merged)). The scenario it guards against is a popular description with many GLQL blocks, viewed by many people, hitting Postgres. Embedded blocks keep the default queue and its concurrency of 1, so that behavior is unchanged. Because the limit was a readiness commitment, the linked work item asks that the reviewers on https://gitlab.com/gitlab-org/gitlab/-/issues/517546 get a heads-up before this merges.

This MR implements glql#222 (closed), filed from a review comment on !256013 (merged) (chart auto-pagination). This MR is independent of that one and is based on master. Both touch the same three execute(...) call sites in resolver.vue, so whichever merges second will need a small rebase.

References

Screenshots or screen recordings

There is no visible UI change. Nothing renders differently; panels only finish loading sooner, so there is nothing to screenshot.

Before After

How to set up and validate locally

  1. Run the Jest suites: yarn jest spec/frontend/glql spec/frontend/analytics/analytics_dashboards/components/visualizations/glql_spec.js.
  2. On a GDK with ClickHouse, open a dashboard with many GLQL panels, for example the DAP Impact dashboard under /explore/analytics_dashboards.
  3. Open the browser network tab and filter on /api/glql.
  4. Before this change, requests are strictly one at a time. After this change, up to four are in flight at once.
  5. Open an issue or MR description with an embedded GLQL block and confirm it still issues one request at a time.

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

Edited by Brandon Labuschagne

Merge request reports

Loading
Loading