Skip to content

WS7: golden-sample contract test (detector drill-down -> dispatchable action)#1083

Merged
erikdarlingdata merged 1 commit into
devfrom
feature/ws7-golden-sample
Jun 8, 2026
Merged

WS7: golden-sample contract test (detector drill-down -> dispatchable action)#1083
erikdarlingdata merged 1 commit into
devfrom
feature/ws7-golden-sample

Conversation

@erikdarlingdata

Copy link
Copy Markdown
Owner

What

Adds RemediationGoldenSampleTests — the dynamic complement to RemediationContractTests' static handler↔key check. This is the golden-sample follow-up that file's scope note explicitly deferred.

For each Apply-able fact key, it feeds a representative detector drill-down — shaped to match what the drill-down collectors emit (SqlServerDrillDownCollector / Lite DrillDownCollector; each fixture cites its emit site) — through the FactRemediation builder AnalysisService applies, and asserts a non-null action whose FactKey resolves through the production handler registry:

Fact key Builder Handler
PLAN_REGRESSION BuildAction ForcePlanHandler
DB_CONFIG BuildAction DbConfigHandler
RCSI BuildRcsiAction RcsiHandler (destructive)
CLEAR_PLAN BuildClearPlanAction ClearPlanHandler (destructive)
FILE_AUTOGROWTH_PERCENT BuildFileAutogrowthAction FileAutogrowthHandler
SERVER_CONFIG BuildServerConfigAction ServerConfigHandler

Plus a completeness test: every registered Apply-able handler key must have a golden fixture producing a dispatchable action — so the Apply-able surface can't grow without a fixture.

Why

This is the "autogrowth-CTE-drift" guard at the dynamic level: if a builder stops reading a drill-down key the detector emits (rename / typo / extractor refactor), the action comes back null and the matching test fails loudly — instead of Apply silently no-opping (RemediationRunStatus.NoHandler) in production. The static contract test locks the handler↔key set; this locks that real drill-down still flows through to a dispatchable action.

Residual limitation (documented in the test)

Fixtures are captured from the collector emit at authoring time and catch builder-side drift immediately. A future collector-side key rename is caught only when the fixtures are regenerated against the new emit — the fixtures are the contract, kept in sync with the cited emit sites. (A shared drill-down key-name constant set would make this automatic; larger refactor, out of scope.)

Tests

Dashboard.Tests: 467 passed / 0 failed (+7 from this PR). Test-only change — no production code touched.

🤖 Generated with Claude Code

Adds RemediationGoldenSampleTests -- the dynamic complement to
RemediationContractTests' static handler<->key check. For each Apply-able fact
key it feeds a representative detector drill-down (shaped to match the drill-down
collectors' emit, each fixture citing its emit site) through the FactRemediation
builder AnalysisService applies, and asserts a non-null action whose FactKey
resolves through the production handler registry. This is the autogrowth-CTE-drift
guard at the dynamic level: a builder that stops reading a drill-down key the
detector emits now fails loudly instead of letting Apply silently no-op.

Includes a completeness check -- every registered Apply-able handler key must have
a golden fixture producing a dispatchable action (forces a fixture whenever the
Apply-able surface grows). Updates the RemediationContractTests scope note to point
at the implemented follow-up.

Dashboard.Tests: 467 passed / 0 failed.

Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
@erikdarlingdata erikdarlingdata merged commit 57c39c6 into dev Jun 8, 2026
2 checks passed
@erikdarlingdata erikdarlingdata deleted the feature/ws7-golden-sample branch June 8, 2026 19:43
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