3.5.1 release prep: version bump and changelog cut

[erikdarlingdata]

Version bump to 3.5.1 across the three live csprojs plus the deprecated Dashboard csproj that the dev→main version check reads, and the changelog cut.

3.5.1 is a patch release for two defects 3.5.0 itself introduced, both of which are silent:

• Cap the plan dimension's purge by rows instead of by a time slice #2388 / Tightening plan_content_retention_days permanently stops retention on query_plan_dim (one-day slice exceeds the 300s delete timeout) #2386 — plan-dimension retention bounded its DELETE by a time slice rather than by rows. Slice width is set by data at the old end, not by how far behind retention is, so the statement could exceed the 300s timeout and roll back to zero rows deleted — or, worse, succeed on a thin slice and log 0 failed while the table grew. Measured on the dogfood store: deleting ~6% of what crossed the horizon, falling ~360k rows/day behind, 1.16M expired rows accumulated. Evidence on Tightening plan_content_retention_days permanently stops retention on query_plan_dim (one-day slice exceeds the 300s delete timeout) #2386.
• Bound PLAN_REGRESSION on the partitioning column too #2390 — the PLAN_REGRESSION analysis query never bounded the partitioning column, so chunk exclusion could not engage and every run read the whole query_store_stats history.

Plus #2391 (file-growth knobs reachable on all three surfaces), #2384 (SHA256SUMS written with LF so shasum -c works), and #2385 (fixture doc comment corrected).

check-version is expected RED on this PR — it compares against main and only goes green once dev→main merges. That is the same behavior as the 3.5.0 cut.

[claude]

Reviewed. This is a pure release-prep PR (version bump + changelog) — no T-SQL, no application code, so the usual style/parity/security/perf checks don't have anything to bite on. Verified the mechanics:

• All four <Version> bumps (Darling.Service, Darling.Viewer, Lite, deprecated Dashboard) are consistently 3.5.0 → 3.5.1.
• deprecated/Dashboard/Dashboard.csproj is correctly included — check-version-bump.yml reads that specific file for its dev→main comparison, matching what the PR description says.
• All six new changelog reference links (#2384, #2385, #2386, #2388, #2390, #2391) resolve and aren't duplicated against existing definitions later in the file; the reused #2349 link was already defined from the 3.5.0 entry.
• Changelog date (2026-08-21) matches today.

No findings — nothing to flag on correctness, Lite/Darling parity, security, or performance grounds for this diff.

[erikdarlingdata]

Putting this back to draft — I cut it before validating the thing it exists to fix, which is the same gap that let #2386 and #2387 ship in 3.5.0 in the first place.

#2388's batched drain has never run against real data. Its coverage is a fake-executor loop test plus a string assertion on the SQL; the two have never met a real planner together. #2397 adds that (110 expired rows, cap 25, asserts the total and the batch count), and it runs under DARLING_TEST_PG in CI.

Gate for taking this out of draft:

1. Prove the row-capped drain actually drains, against real PostgreSQL #2397 green — the drain provably drains rather than peeling one slice.
2. A build carrying Cap the plan dimension's purge by rows instead of by a time slice #2388 on prod-pos-use2-monitor-01, watched through at least one purge cycle, showing the 1.16 M-row backlog actually falling. That store is the exact condition the fix targets and it is sitting right there.

The measurement to watch is query_plan_dim row count day over day, not the purge log — the log said 0 failed throughout the week it was falling ~360k rows/day behind.

[claude]

[#2376] is referenced here but has no corresponding link definition added to the reference list at the bottom of the file (the other seven new references — #2384, #2385, #2386, #2388, #2390, #2391, #2396 — all got one; #2349 already had one from the 3.5.0 entry). As-is this will render as literal [#2376] text instead of a link.

Suggested change

	- **The DuckDB test fixture's doc comment now describes what class-per-database actually buys** ([#2385], [#2396], [#2376]) - it claimed the `IClassFixture` choice kept xUnit's cross-class parallelism intact, which `DuckDbInitializer`'s process-wide lock does not permit. The file separation is real and worth having; the parallelism claim was not, and a comment asserting a property the code does not hold is worse than no comment when the next person is deciding whether to change the topology. The first correction then overshot in the other direction - it said every read and write queues on one lock, which is not what a `ReaderWriterLockSlim` does: readers do not queue behind each other, and the suite is overwhelmingly readers (~184 read call sites against ~20 write sites), so the contention is writer-driven and bursty around archival, compaction and CHECKPOINT rather than a flat tax. That distinction decides what a fix could look like, since a collection fixture would serialize the readers too and cannot help writer-driven contention.
	- **The DuckDB test fixture's doc comment now describes what class-per-database actually buys** ([#2385], [#2396], [#2376]) - it claimed the `IClassFixture` choice kept xUnit's cross-class parallelism intact, which `DuckDbInitializer`'s process-wide lock does not permit. The file separation is real and worth having; the parallelism claim was not, and a comment asserting a property the code does not hold is worse than no comment when the next person is deciding whether to change the topology. The first correction then overshot in the other direction - it said every read and write queues on one lock, which is not what a `ReaderWriterLockSlim` does: readers do not queue behind each other, and the suite is overwhelmingly readers (~184 read call sites against ~20 write sites), so the contention is writer-driven and bursty around archival, compaction and CHECKPOINT rather than a flat tax. That distinction decides what a fix could look like, since a collection fixture would serialize the readers too and cannot help writer-driven contention.
	[#2376]: https://github.com/erikdarlingdata/PerformanceMonitor/issues/2376

[claude]

Reviewed. This is a low-risk, mechanical release-prep PR (version bump + changelog cut, no application or T-SQL code) — verified:

• All four version-bearing csprojs (Darling Service, Darling Viewer, Lite, deprecated Dashboard) are consistently bumped 3.5.0 → 3.5.1. The two other deprecated Installer csprojs correctly stay untouched — they're not read by check-version-bump.yml and aren't part of the "live" set the PR description calls out.
• check-version-bump.yml's job only runs if: github.head_ref == 'dev', so on this release/3.5.1 branch it's simply skipped, not red — matches the PR description's caveat in spirit, just worth noting for anyone confused by the check not appearing at all.
• Changelog entry date (2026-08-21) matches today, format matches prior entries (Keep a Changelog style, bold lead sentence + issue links per bullet).
• Left one inline comment: [#2376] is cited in the "Changed" bullet but has no link definition added to the reference list at the bottom of the file, unlike the other seven new references in this entry — it'll render as literal bracket text.

No Lite/Darling parity concerns (both apps' versions move together), no security-relevant surface touched.

[erikdarlingdata]

Both gate conditions are met, so this is out of draft.

1. #2397 green — the live drain test ran against real PostgreSQL (confirmed executed, not skipped: DARLING_TEST_PG was set, 5306 tests, and the payload-dimension skip reason appears zero times in the job log).

2. Verified on the box in the failure state. dev went onto prod-pos-use2-monitor-01 and the restart-triggered purge was caught mid-run:

pid 2772 | active | 00:00:12.3 | DELETE FROM query_plan_dim WHERE ctid IN (
    SELECT ctid FROM query_plan_dim WHERE last_seen < $1 ORDER BY last_seen LIMIT 50000)

10:46:00  Retention purge: 58 table(s) purged, 451644 row(s) deleted, 23 chunk(s) dropped, 0 failed, 340034ms

Against four consecutive runs on 08-19 that hit ~301 s and deleted zero rows each. Afterwards: 0 rows past 23 days, oldest surviving last_seen exactly 22.0 days old.

Scope stays as cut, deliberately

dev is now 33 commits ahead of this branch and has picked up real features — Lite's MCP alert-settings parity (#2410), the update-check switch (#2415), settings.sample.json (#2423), the AG and connection groups (#2421). Folding those in would enlarge the risk surface of a release whose entire purpose is two silent regressions, and would use a patch number for a feature release.

So this ships what it says it ships. Every item in it — #2388, #2390, #2391, #2384, #2385 — is in the build currently soaking on all three monitor boxes, so the contents are validated rather than merely merged. dev accumulates toward 3.6.0.

One correction to my own gate note above: I wrote that the 1.16 M figure was the backlog. It was measured against now() - 21 days, the knob value, and the purge cuts at knob+1. Measured correctly the eligible set was far smaller, and the "falling 360k rows/day behind" reading was a category error — comparing deletions against total row growth, most of which is rows too young to be eligible. The defect being fixed is unaffected: four runs deleting zero rows because an unbounded DELETE that hits the timeout rolls back everything. Full correction on #2386.