The WPF Viewer computes the fleet deadlock total a third time, with the same structural-zero defect — and sharing the coverage type crosses an assembly boundary #3029

The WPF Viewer computes the fleet deadlock total a third time, independently of the MCP tool and the web dashboard, and it carries the same structural-zero defect #3017 was filed about. Fixing it is not a rendering change — it crosses an assembly boundary — which is why it is filed here rather than folded into #3027.

The finding

Darling/PerformanceMonitor.Darling.Viewer/ViewerDataService.Fleet.cs's FleetTotalsSql runs its own:

SELECT COUNT(*) FROM v_deadlocks WHERE deadlock_time >= $1 AND deadlock_time <= $2

That reaches the WPF Overview through FleetRollup.Build → MainWindow.xaml:876, as a bare binding:

Text="{Binding TotalDeadlocks, StringFormat='Deadlocks: {0}'}"

On a PostgreSQL fleet it is structurally zero forever, exactly as get_fleet_overview was — v_deadlocks is written only by the SQL Server extended-event collector, and no v_pg_deadlocks exists. Same defect, same argument, different assembly.

And the same ambiguity: zero is also what a genuinely quiet SQL Server fleet reports, so the reading that needs no action and the reading that means "this total does not cover your fleet" are indistinguishable.

Why this is not the client-rendering change #3027 already shipped

Checked rather than assumed:

• PerformanceMonitor.Darling.Viewer does not reference PerformanceMonitor.Darling.Service. Its ProjectReferences are Common, Ui, PlanAnalysis, Alerting, Analysis, Notifications, Darling.Analysis, Collectors, Darling.Storage. So FleetDeadlockSource, FleetDeadlockCoverage and ClassifyDeadlockSource are unreachable from it.

  Sharing them means moving a public enum, a public DTO and a classify method out of the Service into Common. That is arguably the right home — "banding lives once" is this codebase's own line — but it is a public type crossing assemblies, and the Service's JSON-shape pins have to be re-verified afterward.

• The Viewer's Overview read selects no engine_kind at all. engine_kind appears only in ViewerDataService.MonitoredServers.cs and ViewerDataService.cs, never on the Overview path, and ServerSummaryItem carries no PostgreSQL flag. Both the read and the DTO have to grow one.

• The Viewer's summary path keeps only a FAILING count, not the per-collector band, so the deadlocks collector's band has to be retained through it the way the service reader now does.

• Plus MainWindow.xaml and ViewerFleetRollupTests.cs (626 lines).

Roughly five more files including the cross-assembly move.

Why it was split rather than folded

#3027 was already at review shape on a ~1000-line dual-gate diff, and its routing instruction was explicitly "no server-side change" — which this cannot honour. The cross-assembly public-type relocation is a different review class and deserves its own reviewers' full attention rather than a rider slot on a diff that size. Same call as #3017 item 3, which also went to its own lane.

The costing above is carried over verbatim so whoever picks this up starts from the ProjectReference facts rather than rediscovering them.

What a fix has to decide

• Where the shared types live. Common is the obvious home if "banding lives once" holds, but the move has to leave the Service's existing JSON-shape pins green.
• Whether the Viewer needs the full coverage object or a narrower signal. The web tile takes servers_read/servers_total and renders a sub-line; the WPF Overview is a single bound string today and may want something different.
• What the tile shows when coverage is complete, which Fixes #3017 (items 1 and 2) #3027 had to decide for the web surface — a permanent "12 of 12" trains people to ignore it, while showing something only on incomplete coverage means absence carries meaning.

Priority

Same defect family as #3017, so it inherits that priority rather than urgency. Nothing is newly broken; the number has read this way for as long as the Viewer has had the tile.