Darling: live Current Active Queries via service-mediated command

[erikdarlingdata]

What

Adds a LIVE, on-demand "Current Active Queries" view to the Darling viewer — a DMV snapshot of what is running on a monitored server right now. Because Darling's viewer is store-only (no live SQL connection), it is delivered through the Stage-2 command plane exactly like execute_actual_plan / fetch_plan: the viewer enqueues a new fetch_active_queries command, the SERVICE (which holds a live connection to every monitored server) runs the query on demand and returns the rows in result_json, and the viewer renders them. This is the distinct LIVE counterpart of the collector's stored hourly "Active Queries" snapshot.

Command plane (mirrors fetch_plan)

• New CommandKind.FetchActiveQueries + case "fetch_active_queries" in DarlingCommandExecutor.ResolvePlan (requires target_server_id, takes no args), and the RunAsync dispatch to IDarlingCommandHost.FetchActiveQueriesLiveAsync.
• WorkerCommandHost + DarlingWorker.RunFetchActiveQueriesLiveAsync resolve the runtime under the _serversLock, return legible not monitored / not connected / timed out / permission denied / sql error outcomes (mirroring RunFetchPlanAsync / RunExecuteActualPlanAsync), and cap the SQL read at 30s — comfortably under the viewer's 60s poll budget so the viewer sees a real timeout, not a poll miss (pinned by a test).
• Data returns via result_json (jsonb); the command row is deleted after read (like fetch_plan / test_connect) since a live snapshot with inline plans can be large. Failure-isolated by the executor's ExecuteAndReportAsync.
• Read-only DMV read (sys.dm_exec_requests/sessions + the sql_text / query_plan DMFs), so — unlike execute_actual_plan — it is not consent-class, but it still rides the same read-write-seat-only enqueue as every other command.

DMV query REUSED (not reinvented)

DarlingCollectorRunner.FetchRowsAsync runs the shared QuerySnapshotsCollector (BuildQuery + ReadAsync) against the live connection and returns the rows without writing to the store — the read-only "fetch phase only" twin of RunAsync, building the SAME CollectorContext the scheduled sweep builds. So the live snapshot carries the SAME columns as the stored one.

Viewer

• ViewerDataService.RequestActiveQueriesLiveAsync enqueues → polls → deletes the row → parses result_json into ViewerQuerySnapshotRow (the stored grid's model), with read-only-seat / timeout / failure handling.
• New "Current Active Queries" sub-tab (index 2, right after the stored "Active Queries" tab) with a Refresh button. On-demand only — never auto-fetched on tab selection or a range refresh (a live server hit is an explicit action). Estimated/Actual plan buttons reuse the stored grid's handlers on the plan the DMV read carried inline.

Tests (Darling.Tests green; builds clean)

• Pins the command constant viewer↔executor (ViewerDataService.CommandFetchActiveQueries → CommandKind.FetchActiveQueries), the ResolvePlan case, and the full service-serialize → viewer-parse wire contract (no live SQL Server needed), plus the timeout / failure mappings and the poll-budget-vs-SQL-cap ordering.
• Live fetch_active_queries executor round-trip gated on DARLING_TEST_PG (skips in CI) like the existing fetch_plan round-trip.

Darling-only — no Lite, Full Dashboard, or install/*.sql changes. No live SQL Server was hit during development.

🤖 Generated with Claude Code