Collection Health: count SKIPPED as a healthy run (no false STALE for dedup collectors)#1248
Merged
Merged
Conversation
…E for dedup collectors) Dedup-snapshot collectors (server_properties + the config snapshots) log SKIPPED when nothing changed -- a successful no-op. But the per-collector health computed last_success_time from SUCCESS only, so a collector that's correctly skipping showed STALE, then NEVER_RUN once its last real SUCCESS aged out of log retention. This is the same "SKIPPED is fine" semantics #1246's freshness backstop already uses. Dashboard (report.collection_health view, install/47): SKIPPED now counts toward last_success_time and total_runs, and is included in the recent_failures window so a skip-only collector doesn't fall through to the consecutive_failures FAILING branch. Validated live: server_properties on SQL2016/2017/2025 flips STALE/NEVER_RUN -> HEALTHY. Lite (LocalDataService.CollectionHealth): SKIPPED counts toward last_success_time too, so a version-gated/dedup collector not on the OnLoadCollectors exemption list no longer false-STALEs. Build clean, 618 Lite.Tests pass. Parity fix, both apps. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This was referenced Jun 28, 2026
Merged
pull Bot
pushed a commit
to ehtick/PerformanceMonitor
that referenced
this pull request
Jun 29, 2026
…lthy fix) erikdarlingdata#1248 (merged to dev) makes per-collector Collection Health count SKIPPED as a healthy run, so dedup / skip-if-unchanged collectors (server_properties + the config snapshots) stop showing false STALE/NEVER_RUN in both apps. Added as a [3.1.0] Fixed entry + reference link. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Dedup-snapshot collectors (
server_properties+ the config snapshots) logSKIPPEDwhen nothing changed — a successful no-op. But per-collector Collection Health computedlast_success_timefromSUCCESSonly, so a collector that's correctly skipping showed STALE, then NEVER_RUN once its last realSUCCESSaged out of log retention. (Same "SKIPPED is fine" semantics #1246's freshness backstop already uses — now consistent.)Dashboard (
report.collection_healthview,install/47):SKIPPEDnow counts towardlast_success_timeandtotal_runs, and is included in therecent_failureswindow so a skip-only collector doesn't fall through to theconsecutive_failures → FAILINGbranch.Lite (
LocalDataService.CollectionHealth):SKIPPEDcounts towardlast_success_timetoo, so a version-gated/dedup collector not on theOnLoadCollectorsexemption list no longer false-STALEs.Validated live:
server_propertieson SQL2016/2017/2025 flipsSTALE/NEVER_RUN→HEALTHYagainst real on-disk data. Lite build clean; 618 Lite.Tests pass. Parity fix, both apps.🤖 Generated with Claude Code