Analysis: server-local analysis window + null-safe blocking analyzer

[erikdarlingdata]

The bug (server-local window)

AnalysisService built the analysis window from DateTime.UtcNow, but every collector stamps rows with SYSDATETIME() (server-local). So all 102 windowed reads (wait/CPU/blocking facts, anomaly detection, every drill-down enrichment) filtered server-local data against a UTC window and silently matched nothing on any non-UTC server — the entire windowed half of the analysis engine was dark there.

Proven on sql2022 (UTC−7): the UTC window saw 0 wait-stats and 0 CPU rows; the server-local window saw 11,050 wait rows + 293 CPU rows.

The fix

• AnalyzeAsync / CollectAndScoreFactsAsync probe the monitored server's clock (SELECT SYSDATETIME(), SYSUTCDATETIME()) and build a server-local window, capturing the UTC offset on AnalysisContext. The 102 windowed reads are unchanged (they consume the context window).
• SqlServerFindingStore converts the window back to UTC for persistence, so stored time_range_*/analysis_time stay UTC — the reader's AsUtc, the deep-link offset math, and the retention purge are all unchanged.
• compare_analysis uses the server clock too. Falls back to host UTC if the probe fails (prior behavior; no new hard-failure mode).

Bundled: null-safe blocking_deadlock_analyzer (install/26)

SUM(wait_time_ms)/MAX(...) and SUM(wait_time) feed NOT NULL columns, but those source columns are nullable — a report missing the duration made the aggregate NULL and failed the whole insert (it was failing on sql2022). Wrapped in ISNULL(..., 0).

Verification

• get_analysis_facts now returns 292 wait facts (vs 0 before); persisted time_range_end = server SYSUTCDATETIME (UTC), not server-local.
• Analyzer aggregates a NULL-wait_time_ms row to 0 instead of erroring (deployed + tested on sql2022).
• Dashboard + Lite build clean; 346 Dashboard.Tests pass.

🤖 Generated with Claude Code