analyze_server: an empty analysis window is "unavailable", not an all-clear (#3524)

[erikdarlingdata]

What

analyze_server answered "No significant findings. All metrics are within normal ranges." for a server whose collection is dead. The analysis pipeline's data-span gate measures lifetime history, so a server monitored for a month with a credential that broke last Tuesday passes the gate, collects zero facts over the empty window, and the zero-facts pass returned a bare [] that the tool rendered as a true-negative all-clear — in prose, to an operator or their agent.

How

• Both SKUs' analysis services (DarlingAnalysisService, Lite's AnalysisService) now set a distinguishable state, WindowEmptyMessage, beside the existing InsufficientDataMessage, at the zero-facts branch — naming the window, the total history that got it past the gate, and that nothing was measured. The branch also logs a warning (it was previously silent, including on scheduled passes).
• Both SKUs' analyze_server tools check it before the findings-count branch and return the same unavailable envelope get_analysis_facts already uses for this exact state (DarlingMcpTools.cs:201-208 was the honest arm), telling the caller collection appears broken for this window and to check get_collection_health.
• The all-clear is unchanged for the genuine case: facts collected, zero findings.
• The unavailable envelope carries the same analysis_time/persisted/persistence_note hints as the all-clear, so an anchored empty-window run still discloses non-persistence (The analysis family cannot be anchored at a past window, and it is the one an incident starts with #2506 contract preserved — the existing AnalysisAsOfAnchorTests persistence assertions pass unmodified).

Evidence

New tests in both SKUs, run on the real 24h gate (not a zeroed one), covering both sides:

• 25h of history whose newest row is 5h old (gate passes, default 4h window empty) → status: "unavailable", message points at get_collection_health, no "within normal ranges" anywhere, WindowEmptyMessage set, InsufficientDataMessage null.
• Same server plus one benign wait inside the window → status: "empty" with the existing all-clear, WindowEmptyMessage null.

Test results (local):

• Lite (Lite.Tests.exe, MTP): AnalysisWindowEmptyTests (2, new), AnalysisAsOfAnchorTests, AnalysisServiceTests, AnalysisBudgetTests, RemainingEmptyReadsToolTests — 27/27 pass; FactCollectorMiseryTests 23/23 pass.
• Darling (Darling.Tests.exe, MTP, gated classes run live against a throwaway PG 18.4 + TimescaleDB 2.28.1 cluster): AnalyzeWindowEmptyLivePostgresTests (new), AnalysisAsOfAnchorLivePostgresTests, DarlingAnalysisPipelineTests, DarlingMcpToolsTests — 26/26 pass, 0 skipped; ViewerRecommendationsTests, TempDbCeilingStoreTests, DarlingWebEndpointsTests, AnalysisPlanAdvisoryGzReadTests, AnalysisPassCommandTimeoutTests — 94/94 pass.
• Both builds: 0 Warning(s).

Out of scope (filed, not dropped)

The viewer Recommendations tabs (Lite RecommendationsTab, Darling Viewer) render the same "All clear — no current recommendations." from the same state and only branch on InsufficientDataMessage — that's #3551, deliberately outside this fix's file scope. The services' WindowEmptyMessage added here is what the viewers will consume.

Fixes #3524

🤖 Generated with Claude Code

https://claude.ai/code/session_01QMYFB4qv5tqGwMmdPsa4Zx

[claude]

Reviewed. Change is symmetric between Lite (AnalysisService/McpAnalysisTools) and Darling (DarlingAnalysisService/DarlingMcpTools) — same field, same branch placement, same envelope shape. WindowEmptyMessage is correctly reset alongside InsufficientDataMessage at the top of AnalyzeAsync, the two are mutually exclusive (both branches return [] early), and dataSpanHours is in scope at the zero-facts branch in both files. New tests exercise the real 24h gate rather than a zeroed one, matching the PR's own claim.

One thing worth double-checking, not a blocker since the PR body already discloses it: Lite/Controls/RecommendationsTab.xaml.cs (and the Darling Viewer's RecommendationsViewModel) still branch only on InsufficientDataMessage and would render the same all-clear (FromItems([])) for a dead-collector window — i.e. the exact bug this PR fixes for the MCP tool still reproduces in the desktop UI. The PR calls this out explicitly as out-of-scope/filed as #3551, so flagging here only to confirm that's intentional and not an oversight, and that #3551 is tracked to land before this becomes a customer-visible gap in practice.

[claude]

LGTM — verified Lite/Darling parity in the new WindowEmptyMessage field and its MCP-tool branch (identical placement, envelope, and reset logic in both AnalysisService/DarlingAnalysisService and McpAnalysisTools/DarlingMcpTools), checked variable scope (dataSpanHours) and mutual exclusivity with InsufficientDataMessage, and confirmed the referenced test helpers (ServerIdHelper, LiveStoreCleanup, CollectionIdGenerator, SharedDuckDbFixture) exist. No T-SQL touched. The one gap I found (viewer Recommendations tabs not yet updated) is explicitly disclosed in the PR body as filed under #3551, so it's not a hidden drift.