Make replace_index check independent of live database state - #92
Merged
fatkodima merged 1 commit intoJun 18, 2026
Merged
Conversation
The replace_index check only fired when the live connection could resolve the removed index at check time: remove_index recorded into @removed_indexes only when the index physically existed, and add_index skipped the check entirely when that collection was empty. This meant a same-name remove_index/add_index pair in a single migration (the unsafe drop-then-rebuild pattern the check exists to stop) passed silently whenever the index was missing from the connection (schema drift, or a name-only removal whose columns cannot be resolved without the DB). Record every removal, falling back to the migration's declared options (which always include the name) when the connection has no matching index, and match removed-vs-added indexes on name so the check is driven by the migration's own commands rather than live database state.
fatkodima
force-pushed
the
remove-index-check-improvements
branch
from
June 18, 2026 17:00
8c132ca to
092fdb6
Compare
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
2 participants
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.
Failure mode: The check that catches an unsafe same-name remove→add of an index in one migration only fires if the live connection can resolve the removed index. remove_index records into @removed_indexes only when the index physically exists, and add_index skips the check when that's empty. So a name-only remove_index/add_index pair passes silently whenever the index is missing locally (schema drift), the author never sees it before merge.
This PR Fix: Record every removal (falling back to the migration's declared options when the DB has no match), and match removed-vs-added indexes on name in intersect? the one identifier present in both calls. The check is now driven by the migration's own commands, not DB state.
Notes: Name match is only used in the removed-vs-new comparison, so other callers are unaffected. Legit same-name drop-and-rebuild migrations will now raise (correctly. same no-index window); safety_assured { } is the escape hatch. Added tests for the missing-index regression, distinct-name non-matching, and safety_assured.