Run GLQL trend comparisons alongside the main query

Brandon Labuschagnerequested to merge
glql-parallel-comparison into master

What does this MR do and why?

A GLQL panel with a trend comparison (dashboard stat panels using showTrends) ran its comparison query, the same query scoped to the previous period, only after its main query and all of its pages had fully finished. Each trend panel made two request round trips back to back instead of at the same time, which doubled its loading time.

In resolver.vue's executeQuery, the code now starts the main query's request and calls fetchComparison() straight after it, without awaiting the comparison yet. It only awaits that pending promise after the main query and any of its extra pages have finished loading, so the panel still renders once, with both the main data and (if kept) the comparison data set together. Because the main request is started first, it reaches the request queue before the comparison. The existing rule that drops the comparison when the main result spans more than one page (its row count exceeds 100, the auto page size) is kept, but the check moved out of fetchComparison and into executeQuery, evaluated after both requests have finished. fetchComparison itself never rejects: on failure it reports the error to Sentry and resolves to undefined, so a failing comparison can't turn into an unhandled rejection and doesn't affect the main query's own success or failure.

When the main result does span more than one page, the comparison request has, by then, already run to completion, and its result is simply discarded. This should be rare: most trend comparisons are on stat panels, which return a single row.

On master, every GLQL request shares one queue that only runs one request at a time. So on its own, this change is correct (it fixes the request ordering) but saves no wall-clock time, because the shared queue still runs the two requests one after another. The actual time saving only appears once !256168 (merged) merges, which gives dashboard panels their own queue that runs 4 requests at once; only then do the main and comparison requests actually run side by side. This MR is standalone off master and changes the same executeQuery/fetchComparison methods in resolver.vue that !256168 (merged) also changes, so expect a small merge conflict between the two.

References

Screenshots or screen recordings

Not applicable. No visible UI change: the panel still renders once with the same data; only request timing changes.

How to set up and validate locally

  1. Check out this branch together with !256168 (merged) (on its own, the shared single-request queue hides the effect of this change).
  2. Open the DAP Impact dashboard's Overview tab (stat panels with trend comparisons).
  3. Open the browser's network tab and filter to api/glql.
  4. Confirm each trend stat's two requests (main and comparison) start together instead of one after the other.

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