sp_IndexCleanup rule_coverage: create Crap scratch DB; wire into CI - #835
Merged
Conversation
rule_coverage_test.py assumed a pre-existing Crap database. On a long-lived
instance it persists between runs (nothing drops it), so the gap was
invisible; on a freshly-started instance -- every CI container -- Crap has
never existed. run_sql_script connects with -d Crap, so setup failed with
Msg 4060 ("Cannot open database"), which is Level 11 and slipped past the
Level-16 error check: the fixture silently did not build and every
Crap-scoped assertion failed with "found 0". This masqueraded as a
procedure bug (missing PAGE compression recommendations); it was not -- the
procedure emits them correctly on a fresh instance, confirmed directly.
Create Crap if absent (CrapA/CrapB were already created this way) and treat
Msg 4060/911 as fatal in sql_errors so a missing scratch database fails
loudly instead of leaving the suite green. rule_coverage now runs on a fresh
instance, so wire it back into CI as the fourth IndexCleanup runner.
Verified by dropping Crap on a local instance: fails identically to CI
without the fix, passes 40/40 with it.
Co-Authored-By: Claude Opus 4.8 <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.
Roots out why
rule_coverage_test.pyfailed on the CI containers, fixes it, and adds it as the fourth IndexCleanup runner in CI.Root cause (a test-harness gap, not a proc bug)
rule_coverage_test.pyassumed a pre-existingCrapdatabase. On a long-lived instance it persists between runs; on a fresh container it has never existed. The setup connects with-d Crap, so it failed with Msg 4060 ("Cannot open database"), Level 11 — below the harness's Level-16 error check — so setup silently no-op'd and everyCrap-scoped assertion failed with "found 0". This looked like the procedure dropping PAGE compression recommendations on freshly-started servers, but a direct diagnostic on a fresh container proved the procedure emits them correctly (single-table, multi-table, both sqlcmd tools). No proc change.Fix
Crapif absent (CrapA/CrapB were already created this way).sql_errors, so a missing scratch database fails loudly instead of leaving the suite green.rule_coverage_test.pyin the CI IndexCleanup step (now all four runners).Verification
Dropping
Crapon a local instance reproduces the CI failure exactly; with the fix it passes 40/40.🤖 Generated with Claude Code