Skip to content

Add the #3236 CHANGELOG entry (wave consolidation follow-up) - #3269

Merged
erikdarlingdata merged 1 commit into
devfrom
chore/wave-changelog-splice
Sep 10, 2026
Merged

erikdarlingdata merged 1 commit into
devfrom
chore/wave-changelog-splice

Conversation

@erikdarlingdata

Copy link
Copy Markdown
Owner

Adds the #3236 CHANGELOG entry (cadence-aware fleet staleness, PR #3268) via the wave's consolidation protocol - the code PR deliberately carried no CHANGELOG edit. Same byte-verified splice mechanics as #3266: entry atop [Unreleased] ### Fixed, [#3236]: reference in numeric order, census 3617 -> 3619 LF with zero lone endings, staged blob asserted equal to the computed one.

🤖 Generated with Claude Code

https://claude.ai/code/session_01Dqza1QNL4YCFS1MpzezERn

The wave's fix PRs deliberately carried no CHANGELOG edits (parallel-agent hot-spot protocol); each agent reported its entry and this commit lands them together, byte-verified against origin/dev.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Dqza1QNL4YCFS1MpzezERn
@claude

claude Bot commented Sep 10, 2026

Copy link
Copy Markdown

Reviewed. This is a clean, CHANGELOG-only change — no T-SQL, C#, or Lite/Darling code touched, so the usual correctness/parity/security/performance concerns don't apply here.

Checked:

No blocking issues found. LGTM.

@erikdarlingdata
erikdarlingdata merged commit 616091a into dev Sep 10, 2026
8 checks passed
@erikdarlingdata
erikdarlingdata deleted the chore/wave-changelog-splice branch September 10, 2026 07:13
pull Bot pushed a commit to ehtick/PerformanceMonitor that referenced this pull request Sep 10, 2026
…erikdarlingdata#3236)

Reverts PR erikdarlingdata#3268 and its CHANGELOG entry (erikdarlingdata#3269). Field review against the pgmon store showed the change is a net regression: EffectiveStaleThreshold takes the max over a server's collectors, so any enabled slow-cadence collector (these PG targets carry 9 hourly + 4 daily) pushes the per-server stale cutoff to tens of hours, while ClassifyFreshness checks the flat 30-minute Offline band first. That leaves the amber Stale band unreachable on every real target: a server reads Fresh until 30 minutes fully dark, then jumps to Offline, so a multi-minute collection gap now shows green. The original erikdarlingdata#3236 signature was a true positive (a real coverage collapse during the nightly restart), not the false positive the fix assumed, because last_collection is MAX over all collectors and the ~70s collectors keep it current on a healthy server. Reopening erikdarlingdata#3236 to re-diagnose with fleet measurement in the loop.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Dqza1QNL4YCFS1MpzezERn
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant