Fix rename index collides with existing v2 index#16560
Merged
Conversation
Contributor
There was a problem hiding this comment.
Your free trial has ended. If you'd like to continue receiving code reviews, you can add a payment method here.
...wenty-server/src/database/commands/upgrade-version-command/1-13/1-13-rename-index.command.ts
Show resolved
Hide resolved
Contributor
There was a problem hiding this comment.
1 issue found across 1 file
Prompt for AI agents (all 1 issues)
Check if these issues are valid — if so, understand the root cause of each and fix them.
<file name="packages/twenty-server/src/database/commands/upgrade-version-command/1-13/1-13-rename-index.command.ts">
<violation number="1" location="packages/twenty-server/src/database/commands/upgrade-version-command/1-13/1-13-rename-index.command.ts:173">
P1: Missing transaction for delete+drop operations in 42P07 error handler. Unlike the earlier block (lines 100-121) which wraps the same two operations in a transaction, this error handler performs them without atomicity guarantees. If `DROP INDEX` fails after metadata deletion succeeds, the database will be in an inconsistent state.</violation>
</file>
Reply to cubic to teach it or ask questions. Re-run a review with @cubic-dev-ai review this PR
...wenty-server/src/database/commands/upgrade-version-command/1-13/1-13-rename-index.command.ts
Show resolved
Hide resolved
Weiko
approved these changes
Dec 15, 2025
prastoin
added a commit
that referenced
this pull request
Dec 15, 2025
## Introduction When migrating a v1 index name to v2 it might collide with an existing v2 index In this case we remove both the v1 metadata and pg index In case of a metadata and pg_index desync this might occur too late in the process that's why we have two fallback One computing the v1 deletion from the metadata and another one in the catch block of the v1 to migration transaction commit
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
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.
Introduction
When migrating a v1 index name to v2 it might collide with an existing v2 index
In this case we remove both the v1 metadata and pg index
In case of a metadata and pg_index desync this might occur too late in the process that's why we have two fallback
One computing the v1 deletion from the metadata and another one in the catch block of the v1 to migration transaction commit