Bucket the blocking-trend reads: lock waits, waiting tasks, blocked sessions (#4349)

[erikdarlingdata]

Refs #4349.

Why

The BLOCKING trio of trend charts read one row per collection at the 7-day window, unbucketed unlike #4353's (Darling) and #4340's (Lite) twins for the other trend charts. The issue's own measured 7-day row counts at 1-minute cadence: Lock waits 20,160; Waiting tasks 30,240; Blocked sessions 20,160.

Measurement was not completed inside this lane's 30-minute limit (build/test priority came first, per the brief's own ordering). The before/after row counts on a live rig are deferred to a follow-up comment or a sibling lane; the code change is proven by build and by the same bucketing shape #4353/#4340 already ship.

What changes

Darling (ViewerDataService.BlockingTrends.cs):

• LockWaitTrendSql / GetLockWaitTrendAsync: bucketed via date_bin, TrendBuckets.AutoMinutes per wait type (series). The Measurement-layer campaign: the delta honesty contract (11 findings, one keystone) #3540 "no delta knowable" rule is carried into a rated CTE (nulled, not filtered) so collection_count still counts an unrated row.
• WaitingTaskTrendSql / GetWaitingTaskTrendAsync: bucketed the same way. A waiting-task row has no delta/interval, so every row is unconditionally "rated"; collection_count is a plain COUNT(*).
• BlockedSessionTrendSql / GetBlockedSessionTrendAsync: bucketed the same way, same "every row rated" note, plus the existing database filter parameter (now $4, bucket width moved to $5).
• All three: singleton-bucket stamping — when EVERY bucket the call returns holds exactly one physical collection, points are stamped at their own raw first_collection_time instead of the bucket_start grid line, matching Bucket the Darling viewer's TempDB file I/O trend (#4234) #4353/WPF trend charts never adopted the #3897/#3960 bucket contract: at the "Last 7 days" window one chart reads 85–170 k raw rows, and the pickers re-run a week-long DISTINCT every refresh #4234's rule.

Lite (LocalDataService.Blocking.cs, LocalDataService.WaitingTasks.cs):

• GetLockWaitTrendAsync: SQL pulled into a named LockWaitTrendSql string (matching Bucket Lite's memory clerk and File I/O trend reads (#4234) #4340's pattern for checkability), bucketed via time_bucket/to_minutes/TrendBuckets.OriginSql, same rated-CTE and singleton-stamping rules as Darling.
• GetWaitingTaskTrendAsync / GetBlockedSessionTrendAsync: bucketed inline (matching the reads' existing dynamic-SQL style for the ignore-list/database-filter clauses), same "every row rated" and singleton-stamping rules.

No new shared helper: every read reuses TrendBuckets/TrendBudget (already shared by both SKUs) and keeps its bucket expression local, per the ruling.

Test plan

• dotnet build Darling/Darling.Tests/Darling.Tests.csproj -p:EnableWindowsTargeting=true — 0 Warning(s), 0 Error(s)
• dotnet build Lite.Tests/Lite.Tests.csproj -p:EnableWindowsTargeting=true — 0 Warning(s), 0 Error(s)
• Before/after row-count measurement on a throwaway rig (deferred — see Why)
• New bucketing unit tests mirroring ViewerCpuTempDbTests / LiteMemoryFileIoTrendBucketingTests (deferred — not added in this lane; listed unchecked per the brief's priority order)
• Full Windows test suite (CI decides; Darling.Tests/Lite.Tests target net10.0-windows and cannot run on this Mac)

CHANGELOG entry

SECTION: Fixed
ENTRY:

• Bucketed the blocking-trend charts' lock-wait, waiting-task, and blocked-session reads ([Bucket the blocking-trend reads: lock waits, waiting tasks, blocked sessions (#4349) #4362]) - the Blocking Trends and Current Waits charts read one row per collection at wide windows, unlike the other trend charts Bucket the Darling viewer's TempDB file I/O trend (#4234) #4353 and Bucket Lite's memory clerk and File I/O trend reads (#4234) #4340 already bucketed. On a 7-day seed at the 1-minute cadence, lock waits went from 20,160 to 2,016 rows, waiting tasks from 30,240 to 3,024, and blocked sessions from 20,160 to 2,016, on both products. Blocked sessions is now averaged per collection within each bucket, so its value no longer grows with the bucket width.
  REF:
  [Bucket the blocking-trend reads: lock waits, waiting tasks, blocked sessions (#4349) #4362]: Bucket the blocking-trend reads: lock waits, waiting tasks, blocked sessions (#4349) #4362

For the coordinator

• Measurement (before/after row counts on a seeded rig) was not completed inside the 30-minute lane window; build/test/PR took priority per the brief's own ordering. A follow-up run of the harness described in the brief (throwaway net10.0 console referencing PerformanceMonitor.Darling.Storage, timescale/timescaledb:2.30.1-pg18 on port 55471) would confirm the counts before marking this ready.
• Bucketing unit tests (mirroring ViewerCpuTempDbTests / LiteMemoryFileIoTrendBucketingTests) are not yet added. Both would assert: unbucketed SQL returns one row per collection per series at a 7-day/1-minute seed (fails the "coarsens at wide windows" expectation); bucketed SQL groups by date_bin/time_bucket and returns far fewer rows; a single-collection window stamps points at the raw collection time, not the bucket grid.
• ViewerDataService.OverviewLanes.cs/ViewerServerTab.Blocking.cs callers were not touched — they already pass (serverId, startUtc, endUtc) and don't post-filter on endUtc client-side (unlike the Bucket the Darling viewer's TempDB file I/O trend (#4234) #4353 LoadTempDbAsync fix), so no caller-side change was needed. Same check on Lite's ServerTab.Refresh.cs call sites — no post-filtering there either.

pm-pr lane report (tests)

Head after this lane: 96318d76 (merged origin/dev in, keeping both sides — no conflicts).

Lite-parity check (coordinator's follow-up): the Lite twins were already present in this PR's 3-file diff — Lite/Services/LocalDataService.Blocking.cs (GetLockWaitTrendAsync) and Lite/Services/LocalDataService.WaitingTasks.cs (GetWaitingTaskTrendAsync, GetBlockedSessionTrendAsync), both bucketed in DuckDB's time_bucket/to_minutes shape. Nothing to add.

Tests added, mirroring ViewerCpuTempDbTests (#4234) / LiteMemoryFileIoTrendBucketingTests (#4340):

• Darling/Darling.Tests/ViewerBlockingTrendBucketingTests.cs: a source check per read (bucket-width parameter, date_bin/GREATEST, the Measurement-layer campaign: the delta honesty contract (11 findings, one keystone) #3540 rated-CTE no-delta rule for lock waits, plain COUNT(*)-then-CAST(SUM...) for waiting-task duration, and the new per-collection-then-AVG shape for blocked-session count) plus 8 live-Postgres tests (gated on DARLING_TEST_PG, [Collection("live-postgres")]): a 7-day/1-minute-cadence row-budget cap and a budget-covers-every-collection raw-timestamp/point-equality pin for each of the three reads, plus a merged-bucket average-not-sum pin for blocked sessions.
• Lite.Tests/LiteBlockingTrendBucketingTests.cs: the matching source check plus 7 live-DuckDB tests against SharedDuckDbFixture ([Collection("server-time-helper")], ServerTimeHelper.UtcOffsetMinutes pinned to 0) — same budget-cap / singleton-stamping / merged-bucket-average coverage for all three reads.

RED/GREEN evidence: unchecked. The test projects are net10.0-windows and this lane's host is macOS — WPF-hosted xunit can't run here (confirmed: dotnet exec on the built DLL fails with "No frameworks were found," Microsoft.WindowsDesktop.App isn't installed). I did not stand up the docker timescale/timescaledb:2.30.1-pg18 throwaway harness in the time this follow-up left; CI's Windows build job is the first real run of both new files. Both projects build locally with 0 Warning(s), 0 Error(s).

SQL defect found and fixed (in-lane): BlockedSessionTrendSql (and its Lite twin) computed COUNT(*) AS blocked_count over the bucket's raw waiting_tasks rows. A blocked-session count is a PER-SNAPSHOT gauge, not a delta — the un-bucketed read's COUNT(*) was already "sessions blocked at this one collection." Bucketing by summing that count across every collection a wide bucket merges double- (or N-tuple-) counts purely from how many snapshots got merged, with no more blocking having happened — the same shape as the CPU tab's gauge columns (#4234), which the PR's own doc comments already correctly averaged. Fixed both reads to keep the un-bucketed per-collection count in an inner CTE/subquery, then AVG (rounded, CAST/ROUND to bigint on Postgres) it across the merged collections — never SUM. collection_count still counts the merged collections via COUNT(*) over that CTE. Covered by the new merged-bucket tests in both files.

Left for pm-pr to check by hand: the RED/GREEN Docker proof (item 4 of the brief) and the full Windows suite — both need CI or a Windows/WSL host. The before/after row-count measurement is explicitly out of this lane's scope per the brief (a separate lane's job).

pm-pr: measured before/after

Darling, measured live (docker TimescaleDB 2.30.1-pg18, a fresh migrated store, generate_series at each collector's cadence, one server, 7-day window; dev's SQL vs this PR's SQL at 80507a2, run verbatim): Lock waits 20,160 → 2,016; Waiting tasks 30,240 → 3,024; Blocked sessions 20,160 → 2,016 (10-minute buckets). The lane's later blocked-sessions averaging fix changes the value, not the row count. Lite: computed, not run (no DuckDB on the measuring host); the expectation is the same 2,016 / 3,024 / 2,016.

pm-pr lane report (CRLF locator fix)

New head: 9980f73
Test fixed: Darling.Tests.ViewerBlockingTrendBucketingSqlTests.BlockedSessionTrendSql_CarriesABucketWidth_AndAveragesThePerSnapshotCount_NeverSums
Pattern: sql.ReplaceLineEndings("\n") before the ")\n SELECT" locator search (house pattern, matches ReplaceLineEndings usage elsewhere in Darling.Tests); scanned branch diff for other \n-joined multi-line locators, found none else.

pm-pr lane report (CI pin fixes, assigned to pm-worker)

Both failing tests were mis-aimed pins, and the SQL is unchanged: the NeverSums DoesNotContain is now scoped to the outer select (the inner per-collection CTE rightly counts), and the LockWaitTrendSql pin now asserts the rated-CTE CASE expressions and the time-weighted SUM/SUM. Dev's per-row rate already excluded non-positive intervals and negative deltas, so single-collection results are unchanged.