## Symptom Opening Dashboard 03 "Single queryid analysis" via the **"Query Analysis"** drill-down link from Dashboard 02 leaves every PromQL panel empty (only the SQL "Query text" panel — which doesn't use `$db_name` — renders). Reproducer URL produced by a normal click in Dashboard 02 (the `{postgres}` is what's shipped in the link): ``` /d/db52944d-b025-4e18-b70b-89c0af3e7e41/03-single-queryid-analysis ?var-query_id=<id> &var-cluster_name=default &var-node_name=aws-0-eu-west-1-pooler-supabase-com-postgres &var-db_name=%7Bpostgres%7D ← URL-decoded: {postgres} ``` ## Root cause Variable-format mismatch between source and destination dashboards. - **Dashboard 02** defines `db_name` as `multi: true, includeAll: true`. When Grafana renders this variable into a URL it uses the multi-value notation `{value}` — even when only one value is selected. - **Dashboard 03** defines `db_name` as a plain query variable (`multi: None`). It accepts the literal string `{postgres}` as a single value. - The PromQL on Dashboard 03 then interpolates `datname="$db_name"` → `datname="{postgres}"`, which matches no series. Verified against the live monitoring instance (0.15.0-rc.5, target = Supabase pooler): | Test | Result | |---|---| | `datname` label values in VictoriaMetrics | `measurements, postgres, template0, template1` (no `{postgres}`) | | `pgwatch_pg_stat_statements_calls{queryid="-2118660587534055968"}` | 1 series, 325 463 calls — the queryid exists | | Panel #2 PromQL with `datname="{postgres}"` (what Grafana sends today) | empty | | Same PromQL with `datname="postgres"` | 1 series, healthy | The same broken pattern (`var-db_name=$db_name` in a drill-down URL) ships in Dashboard 02 (24 occurrences), Dashboard 04 (1), and Dashboard 10 (3) — 28 lines total. Every drill-down destination whose own `db_name` variable is single-select (Dashboards 01, 03, 05, 07, 08, 09, 10, 12, 13) inherits the bug. Surveyed shape of the `db_name` variable across the suite: ``` multi=True includeAll=True Dashboard_2_Aggregated_query_analysis.json multi=True includeAll=True Dashboard_4_Wait_Sampling_Dashboard.json multi=None Dashboard_1, _3, _5, _7, _8, _9, _10, _12 multi=False includeAll=True Dashboard_13_Lock_waits.json ← also incoherent ``` ## Fix In the source dashboards' drill-down URLs, replace the manual `&var-db_name=$db_name` with Grafana's `${db_name:queryparam}` formatter. This formatter emits the parameter name itself and renders each selected value separately (one `var-db_name=val` per value, properly URL-encoded), with no `{…}` multi-value wrapper for a single selected value. Concretely: - `Dashboard_2_Aggregated_query_analysis.json` (24 occurrences) - `Dashboard_4_Wait_Sampling_Dashboard.json` (1 occurrence) - `Dashboard_10_Index health.json` (3 occurrences) `postgres_ai_helm/config/grafana/dashboards/` is symlinked to `config/grafana/dashboards/` so a single edit covers both layouts. ## Out of scope (separate work, please don't bundle) 1. Standardize the shape of the `db_name` variable across all 11 dashboards (related to #60). 2. Dashboard 13's incoherent `multi=False, includeAll=true` definition. 3. Restore "All" semantics on the destination dashboards. ## Verification done locally Applied the patch via Grafana API to a live 0.15.0-rc.5 instance and confirmed the stored drill-down URL contains `${db_name:queryparam}` instead of `var-db_name=$db_name`. End-to-end browser click to validate panel population is the next step — covered in the MR test plan.