Spun out of #1833's triage (the reporter's other empty grid). Verified in source, not yet reproduced live on Azure.
query_store_stats is one of two database-scoped collectors that never opted into the Azure per-database connection path (RunsPerDatabase); #1833's fix handles the other one (procedure_stats), but Query Store is design-sized rather than a one-line override, because the collector is built on BuildEnumerationQuery + BuildPerItemQuery while the Azure per-database branch drives BuildQuery.
What happens today on Azure SQL DB:
- The collector runs once on the server entry's own connection (catalog defaults to
master when the entry's Database field is blank).
- Its Azure enumeration cursors candidate databases and probes each via
QUOTENAME(@db) + N'.sys.sp_executesql' (QueryStoreCollector.cs:255-261) — a cross-database three-part reference, which Azure SQL DB rejects for every database, from master or from any user database alike (the repo already documents this behavior class at RunningJobsCollector.cs:148-150).
- Every probe fails into an empty CATCH, the result list comes back empty, and the run logs
SUCCESS with 0 rows.
So even with the Database field set correctly, Query Store data on Azure is never collected — and on a logical server with several databases, a correct fix collects each database's Query Store, which the single-connection shape can't do at all.
Sketch:
- An Azure per-database
BuildQuery variant that does the sys.database_query_store_options eligibility check inline against the current database (actual_state IN (1, 2, 4) AND readonly_reason & 8 = 0, same predicates as the on-prem probe) and returns the per-item payload for DB_NAME().
RunsPerDatabase => target.IsAzureSqlDb, with the enumeration/per-item pair remaining the on-prem path.- The empty CATCH at
QueryStoreCollector.cs:260-261 should record probe failures somewhere visible even on-prem — a database that always fails its probe is currently indistinguishable from a database with Query Store off.
Darling runs the identical shared definition and has the same gap.
🤖 Generated with Claude Code
Spun out of #1833's triage (the reporter's other empty grid). Verified in source, not yet reproduced live on Azure.
query_store_statsis one of two database-scoped collectors that never opted into the Azure per-database connection path (RunsPerDatabase); #1833's fix handles the other one (procedure_stats), but Query Store is design-sized rather than a one-line override, because the collector is built onBuildEnumerationQuery+BuildPerItemQuerywhile the Azure per-database branch drivesBuildQuery.What happens today on Azure SQL DB:
masterwhen the entry's Database field is blank).QUOTENAME(@db) + N'.sys.sp_executesql'(QueryStoreCollector.cs:255-261) — a cross-database three-part reference, which Azure SQL DB rejects for every database, frommasteror from any user database alike (the repo already documents this behavior class atRunningJobsCollector.cs:148-150).SUCCESSwith 0 rows.So even with the Database field set correctly, Query Store data on Azure is never collected — and on a logical server with several databases, a correct fix collects each database's Query Store, which the single-connection shape can't do at all.
Sketch:
BuildQueryvariant that does thesys.database_query_store_optionseligibility check inline against the current database (actual_state IN (1, 2, 4) AND readonly_reason & 8 = 0, same predicates as the on-prem probe) and returns the per-item payload forDB_NAME().RunsPerDatabase => target.IsAzureSqlDb, with the enumeration/per-item pair remaining the on-prem path.QueryStoreCollector.cs:260-261should record probe failures somewhere visible even on-prem — a database that always fails its probe is currently indistinguishable from a database with Query Store off.Darling runs the identical shared definition and has the same gap.
🤖 Generated with Claude Code