WS3 foundation: config-advisory facts root below the 0.5 threshold#1065
Merged
Conversation
…0.5 threshold InferenceEngine.BuildStories only let facts with Severity >= 0.5 become story roots. Config facts (DB_CONFIG, future SERVER_CONFIG) score ~0.3 for a standing misconfig (RCSI off, single auto_shrink), so they NEVER rooted a finding on a quiet server — they only surfaced when an incident amplified them past 0.5 (e.g. LCK_M_S reader/writer contention for RCSI). That's why a healthy server with 9 RCSI-off databases produced zero recommendations: a standing misconfiguration is an ADVISORY the operator should see regardless of current load, not a severity-gated incident. Let config-advisory fact keys root at ANY positive severity. The existing severity-ordered `consumed` traversal still suppresses duplicates: a higher-severity incident story that consumes the config fact (CXPACKET → CONFIG_MAXDOP, LCK_M_S → DB_CONFIG) wins; only an un-consumed config fact roots a standalone recommendation — which also resolves the D6 leaf-fact double-display concern for free. Unit-tested both directions (config roots at 0.3; an incident fact at 0.3 does not). This is the WS3 enabler: with it, DB_CONFIG recommendations (and the new SERVER_CONFIG facts to follow) appear on any server that actually has the issue. 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.
What
InferenceEngine.BuildStoriesonly rooted facts withSeverity >= 0.5. Config facts (DB_CONFIG, and theSERVER_CONFIGfacts coming in WS3) score ~0.3 for a standing misconfig, so they never rooted a finding on a quiet server — they only appeared when an incident amplified them past 0.5 (e.g.LCK_M_Scontention for RCSI). That's the root cause of the "healthy server shows 0 recommendations despite 9 RCSI-off DBs" sparseness.Change
Config-advisory fact keys (
DB_CONFIG,SERVER_CONFIG) now root at any positive severity — a standing misconfiguration is an advisory, not a severity-gated incident. The existing severity-orderedconsumedtraversal still de-dupes: an incident story that consumes the config fact (CXPACKET → CONFIG_MAXDOP) wins; only an un-consumed config fact roots standalone (this also resolves the D6 leaf-fact double-display concern).Unit-tested both directions:
ConfigFact_RootsStandalone_BelowMinimumSeverityandIncidentFact_BelowMinimumSeverity_DoesNotRoot.Effect
With this,
DB_CONFIGrecommendations surface on any server that has the issue — e.g. SQL2022's RCSI-off DBs now produce a recommendation (with the Apply path, since D7+D2 already give it the drill-down + persisted action). The remaining WS3 work (newSERVER_CONFIGfact for MAXDOP/CTFP/memory, etc.) builds on this.Tests
Dashboard.Tests 317/317, Lite.Tests 360/360 — no existing inference scenario shifted.
🤖 Generated with Claude Code