perf(mfe): dispatch host-proxied panel queries concurrently

[harjotgill]

Summary

Remove the standalone HTTP/1 five-query bottleneck from the embedded Grafana host-proxy path. Use the existing multiplexed ceiling (1000) without pretending the Grafana server is using HTTP/2 or changing its protocol.

The minimal MFE boot config defaults http2Enabled to false. fn_app.init() copies only panels/datasources/defaultDatasource from frontend settings, and the backend singleton constructs its worker before initialization. Consequently panels queued behind five unresolved requests despite independent backend queries.

FetchQueueWorker now reads the existing host-proxy mode when dispatching. Standalone HTTP/1 retains five, standalone HTTP/2 retains1000, API requests retain precedence, and request cancellation/error handling is unchanged. This applies to embedded query transport, not SQL authority: Handler still owns authentication, tenant/repository/provider scope and the separate restricted custom-SQL path.

Evidence and validation

• Internal Summary7d on the previous deployed revision completed within(44.6,48.8]s; last category jobs were created ~42s after navigation but took only2.1–2.2s in BigQuery. This is supporting timing, not a measured improvement from this patch.
  -41 queue/backend transport tests pass.22 unresolved panel requests dispatch22 through the host proxy versus5 standalone. Late mode activation, API priority, the multiplexed ceiling, and existing transport failures/cancellation are covered.
• The transport suite now mocks its unrelated dashboard persistence adapter to avoid a scene/store circular import during test startup. Queue/transport implementations are real.
• Scoped Prettier/ESLint and git diff --check pass.
• Production yarn build and all11 prerequisites pass; existing bundle-size warnings remain.
• No full typecheck pass claimed; previous PR267 documented unrelated existing full-check failures.

Rollout / rollback

Normal review/checks followed by the authorized Grafana deployment. Verify real internal full-page cold/warm timings and errors after deployment; no performance acceptance is claimed yet. Revert this source change if needed; do not roll back unrelated services or alter reader flags. No IAM, SQL, credentials, ingestion, writers, table contracts or residency changes.

Handoff

User intent: complete the lean metrics migration and remove unnecessary serial bottlenecks. Existing Grafana checkout reused, branch codex/mfe-query-dispatch, base coderabbit_micro_frontend at c2f912c. Generated MFE HTML remains excluded. Follow normal review/merge controls; Grafana deployments are already explicitly authorized. Next: production internal end-to-end acceptance and remaining panels/filters/isolation/parity checks.

Summary by CodeRabbit

• Performance
  • Requests sent through a host proxy can now run with a higher level of concurrency, including when proxying is enabled after the request worker starts.
  • API requests retain priority when many requests are in progress, helping important API calls proceed ahead of data requests.
  • Without HTTP/2 or host proxying, the existing lower concurrency limit remains unchanged.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Central YAML (base), Organization UI (inherited)

Review profile: CHILL

Plan: Enterprise

Run ID: beef63e1-1de8-4823-a336-4767cfa8c845

📥 Commits

Reviewing files that changed from the base of the PR and between c2f912c and 2df5564.

📒 Files selected for processing (4)

• public/app/core/services/FetchQueueWorker.test.ts
• public/app/core/services/FetchQueueWorker.ts
• public/app/core/services/backend_srv.ts
• public/app/core/specs/backend_srv.test.ts

🔗 Linked repositories identified

CodeRabbit considers these linked repositories for cross-repo context during reviews:

• coderabbitai/bitbucket (manual)

Included review availability: This review used your included allowance. Your plan provides up to 100 included reviews per hour; 82 remain after this review.

📜 Recent review details

⏰ Context from checks skipped due to timeout. (3)

• GitHub Check: Build
• GitHub Check: Test
• GitHub Check: build-and-test

🧰 Additional context used

📓 Path-based instructions (2)

Do not allow use of `eslint-disable`, `@ts-expect-error`, or `@ts-ignore` unless there's a clear, inline comment explaining why it's necessary.

⚙️ CodeRabbit configuration file

Files:

• public/app/core/specs/backend_srv.test.ts
• public/app/core/services/backend_srv.ts
• public/app/core/services/FetchQueueWorker.test.ts
• public/app/core/services/FetchQueueWorker.ts

We are operating at scale.

⚙️ CodeRabbit configuration file

Files:

• public/app/core/specs/backend_srv.test.ts
• public/app/core/services/backend_srv.ts
• public/app/core/services/FetchQueueWorker.test.ts
• public/app/core/services/FetchQueueWorker.ts

🔇 Additional comments (1)

public/app/core/services/backend_srv.ts (1)

95-95: 🎯 Functional Correctness

The concern is refuted. public/app/fn_app.ts is loaded by the MFE entrypoint public/app/fn-app/create-mfe.ts. The standalone entrypoint public/app/app.ts does not call setGrafanaPrefix(true). The only production path that sets the flag is therefore the embedded MFE path, which matches FetchQueueWorker's host-proxy contract.

---

📝 Walkthrough

Walkthrough

FetchQueueWorker now checks host-proxy mode during each queue update. It uses a limit of 1000 when HTTP/2 is enabled or the host is proxied, and 5 otherwise. API requests retain precedence. Tests cover proxy mode changes, request limits, and backend query transport. Request cancellation and error handling are unchanged.

Priority: ➖ Normal

Severity of issue fixed: Medium

Merge Risk: ⚪ Minimal · up to 2df55

No actionable merge-blocking risk is established for this change. Production performance acceptance remains pending deployment checks.

Security Architecture Review

Security architecture risk: 🟡 Moderate · up to 2df55

Embedded dashboards can now send substantially more queries concurrently through the host proxy. The intended limit may also be exceeded in a late mode-switch scenario. No authentication or tenant-scope bypass was established, but downstream capacity protections could not be verified.

Retained concerns

• Medium · security · inferred: A backlog released after late host-proxy activation can exceed the intended 1000-request data-query ceiling: buffered updates retain old in-progress counts while referring to the subsequently mutated queue state. This could amplify load on the proxy and downstream query services; its production reachability and server-side containment remain unverified.

Security review details

Security Blast Radius

• inferred — Dashboard-driven query volume can now reach the host proxy at substantially higher per-client concurrency. Aggregate service exposure depends on the proxy and downstream admission limits, which were not established by the available source.

Security Findings and Attack Paths

• inferred — If many data requests are pending when proxy mode is activated, a subsequent update can dispatch beyond the intended ceiling because buffered count snapshots and mutable queue state describe different moments. No authentication bypass or cross-tenant access was established.

Trust Boundaries and Controls

• observed — The embedded app sets proxy mode during initialization, while BackendSrv retains client-side organization and datasource-header handling. The available evidence does not verify authentication, tenant scoping, or rate enforcement in the server handler behind the host proxy.

Resilience and Maintainability Implications

• inferred — Synchronous marking of dispatched IDs as in progress supports duplicate suppression, and the existing unsubscribe path removes completed or canceled entries. Those controls do not resolve stale capacity accounting after a bulk selection.

Hardening Proposals

• proposed — Validate the active-request ceiling with the real queues during late mode activation, and account for capacity from a consistent queue state at dispatch. Verify server-side admission limits for bursts arriving through the host proxy.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title clearly and concisely describes the main change: enabling concurrent dispatch of panel queries through the host proxy.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Comment Severity Gate	✅ Passed	No Critical or Major CodeRabbit findings remain outstanding. The current review produced zero actionable findings, and no posted review threads were returned.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

✨ Simplify code

• Commit to this branch
• Create a new PR

---

_{A rabbit watched the queries queue,
Then saw the proxy let more through.
Twenty-two hopped out in flight,
While five stayed for the standalone night.
The bunny twitched its ears with cheer!}

_{Comment @coderabbitai help to get the list of available commands.}