Migrations when custom schema (via search path) fail on v1.12.0 - 'ignore' in migrations does not seem to work

[PlasticLizard]

Bug report

Describe the bug

After upgrading to v1.12.0 using a custom schema (set via connection string per docs), migrations do not run. I get the following error:

query failed: 
        CREATE EXTENSION IF NOT EXISTS pg_trgm;

        CREATE INDEX IF NOT EXISTS idx_gin_product_title ON product USING gin (title gin_trgm_ops) WHERE deleted_at is null;
        CREATE INDEX IF NOT EXISTS idx_gin_product_description ON product USING gin (description gin_trgm_ops) WHERE deleted_at is null;

        CREATE INDEX IF NOT EXISTS idx_gin_product_variant_title ON product_variant USING gin (title gin_trgm_ops) WHERE deleted_at is null;
        CREATE INDEX IF NOT EXISTS idx_gin_product_variant_sku ON product_variant USING gin (sku gin_trgm_ops) WHERE deleted_at is null;

        CREATE INDEX IF NOT EXISTS idx_gin_product_collection ON product_collection USING gin (title gin_trgm_ops) WHERE deleted_at is null;

error: error: operator class "gin_trgm_ops" does not exist for access method "gin"
Could not create pg_trgm extension or indexes, skipping. If you want to use the pg_trgm extension, please install it manually and then run the migration productSearchGinIndexes1679950645254.
query: INSERT INTO "migrations"("timestamp", "name") VALUES ($1, $2) -- PARAMETERS: [1679950645254,"productSearchGinIndexes1679950645254"]
query failed: INSERT INTO "migrations"("timestamp", "name") VALUES ($1, $2) -- PARAMETERS: [1679950645254,"productSearchGinIndexes1679950645254"]
error: error: current transaction is aborted, commands ignored until end of transaction block
query: ROLLBACK

In my case, pg_trgm IS installed. But I think the problem is probably that the extension is installed in public, and maybe the search path is limited exclusively to my custom schema.

I manually created all the indexes, assuming the IF NOT EXISTS would prevent the error, but somehow it did not.

But that isn't the main issue I'm reporting, because I can manually create the indexes. The main issue is that the try/catch in the migration doesn't allow the migration to be skipped as intended because the transaction gets aborted.

I think the only workaround I have at the moment will be to manually run the SQL found in the migrations, and also manually insert the relevant rows into the migrations table, which will work for dev but will be kind of hairy in staging/prod.

System information

Medusa version (including plugins): 1.12.0 Node.js version: 16.15.0 Database: Postgres 15 Operating system: OSX Browser (if relevant):

Steps to reproduce the behavior

1. Create a medusa project using a custom schema
2. Run migrations

Expected behavior

Migrations succeed

[PlasticLizard]

Found a solution to the underlying issue, but not the rollback on caught exception.

I'm using Supabase - extensions there are installed in an extensions schema, not in public.

I was able to solve this by changing the search path in my connection string to medusa,extensions

[sradevski]

Hey, thanks for the report! Since v2 brought a lot of architectural and API changes on the backend, we will be closing this ticket since it no longer applies to our new setup, or the issue has already been fixed. If you are still facing issues with v1, please open a new ticket and we will address it as soon as possible. Thanks! 🙏