Skip to content

Refactor sync metadata to handle index creation if already exists #12757

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Jun 20, 2025

Conversation

guillim
Copy link
Contributor

@guillim guillim commented Jun 20, 2025

In order to put back relations on track, we need to allow the preexisting indexes to be created in indexmetadata, but also to avoid failure when the migration runner will try to re-apply a pre-existing index

@guillim guillim self-assigned this Jun 20, 2025
@guillim guillim requested a review from prastoin June 20, 2025 09:19
Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR Summary

Implements a temporary fix for index creation during version 55 to 56 migration by catching and logging index errors instead of throwing them. This change affects the workspace migration process but raises concerns about the implementation approach.

  • Added hardcoded boolean isv55tov56 in workspace-migration-runner.service.ts to handle index creation errors, which violates clean code principles
  • Using hardcoded version checks (v55tov56) instead of proper migration versioning raises maintainability concerns
  • This temporary solution bypasses proper error handling, potentially masking critical issues
  • Consider implementing a more robust versioning mechanism for handling pre-existing indexes

1 file reviewed, no comments
Edit PR Review Bot Settings | Greptile

Copy link
Contributor Author

@guillim guillim left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ideally, we should check the workspace version to avoid this temp code. But i don't think we have access to this info here

prastoin
prastoin previously approved these changes Jun 20, 2025
Copy link
Contributor

@prastoin prastoin left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me !
Would add maybe a comment with some tags such @guillim @prastoin

@@ -226,7 +226,16 @@ export class WorkspaceMigrationRunnerService {
if (error.code === '42P07') {
return;
}
throw error;

const isv55tov56 = true;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

NItpick: We could be checking APP_VERSION value directly ( ps: we're releasing 0.60 )

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should check the error messageFormat instead, it's not important to check the version IMO, + Add a // TODO

Copy link
Contributor

github-actions bot commented Jun 20, 2025

🚀 Preview Environment Ready!

Your preview environment is available at: http://bore.pub:12436

This environment will automatically shut down when the PR is closed or after 5 hours.

@@ -226,7 +226,14 @@ export class WorkspaceMigrationRunnerService {
if (error.code === '42P07') {
return;
}
throw error;
// TODO: Remove this once we have re-indexed all our relations
if (error.message.includes('already exists')) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i think we should also check for Index :p

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

that's being said we are in the create index function

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM :p

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let's double check the functional behavior:

  • workspace with indexMetadata + IDX in db
  • workspace without indexMetadata and without index in db
  • workspace without indexMetadata but already index in db

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • first one checked locally
    doing the other ones currently

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

does not seem to fix locally the issue. investigating

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note: Also very important to test on mulitple index for one objectmetadata to trigger the transaction failure

Copy link
Contributor Author

@guillim guillim Jun 20, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

locally:
✅ workspace with indexMetadata + IDX in db
✅ workspace without indexMetadata and without index in db
✅ workspace without indexMetadata but already index in db

const whereClause = index.where ? `WHERE ${index.where}` : '';

await queryRunner.query(`
CREATE ${isUnique} INDEX IF NOT EXISTS "${index.name}" ON "${schemaName}"."${tableName}" (${quotedColumns.join(', ')}) ${whereClause}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nitpick: Would still escape params here

@prastoin prastoin dismissed their stale review June 20, 2025 11:57

updates

@prastoin
Copy link
Contributor

@greptileai trigger

Copy link
Contributor

@greptile-apps greptile-apps bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

PR Summary

Refactored index creation logic to use raw SQL queries with 'IF NOT EXISTS' clause instead of TypeORM's TableIndex, providing a more permanent solution for handling pre-existing indexes during migrations.

  • Removed direct TypeORM TableIndex usage in favor of raw SQL queries, improving flexibility and control over index creation
  • Implemented 'IF NOT EXISTS' clause for index creation to prevent failures with pre-existing indexes
  • Consider extracting SQL queries into a dedicated database utility service for better maintainability
  • Ensure consistent error logging and monitoring for index creation operations
  • Consider adding integration tests specifically for index recreation scenarios

1 file reviewed, no comments
Edit PR Review Bot Settings | Greptile

Copy link
Member

@Weiko Weiko left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lgtm + @prastoin comment

@guillim guillim merged commit 3977506 into main Jun 20, 2025
42 checks passed
@guillim guillim deleted the temproary-index-code branch June 20, 2025 12:20
guillim added a commit that referenced this pull request Jun 20, 2025
In order to put back relations on track, we need to allow the
preexisting indexes to be created in indexmetadata, but also to avoid
failure when the migration runner will try to re-apply a pre-existing
index
@prastoin prastoin changed the title temporary code Refactor sync metadata to handle index creation if already exists Jun 20, 2025
ijreilly pushed a commit that referenced this pull request Jun 20, 2025
In order to put back relations on track, we need to allow the
preexisting indexes to be created in indexmetadata, but also to avoid
failure when the migration runner will try to re-apply a pre-existing
index
Copy link

sentry-io bot commented Jun 20, 2025

Suspect Issues

This pull request was deployed and Sentry observed the following issues:

  • ‼️ QueryFailedError: could not create unique index "IDX_UNIQUE_6d269465206d2f3e283ce479b2e" POST /metadata View Issue

Did you find this useful? React with a 👍 or 👎

@prastoin
Copy link
Contributor

Suspect Issues

This pull request was deployed and Sentry observed the following issues:

  • ‼️ QueryFailedError: could not create unique index "IDX_UNIQUE_6d269465206d2f3e283ce479b2e" POST /metadata View Issue

Did you find this useful? React with a 👍 or 👎

Coco is faster than you

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.

4 participants