Prisma•8mo ago

Upgrade from 6.0.1 -> 6.5.0 broke migrate dev

I recently upgraded from 6.0.1 to 6.5.0, and didn't change any migrations or schema files. But when I run

migrate reset

migrate reset

and then run

migrate dev

migrate dev

I am now receiving an exit code of 130 whereas previously I could generate migrations without issue. This happens regardless of if I modify a schema file or not.

The output of the command looks like this:

Drift detected: Your database schema is not in sync with your migration history.

The following is a summary of the differences between the expected database schema given your migrations files, and the actual schema of the database.

It should be understood as the set of changes to get from the expected schema to the actual schema.

[+] Added extensions
  - pg_cron

We need to reset the "public" schema at "localhost:54322"

You may use prisma migrate reset to drop the development database.
All data will be lost.
Command failed with exit code 130: /private/var/folders/1h/l7bdt8tx7c76sr7spy1ndmbh0000gn/T/xfs-20fb55b8/prisma migrate dev

Drift detected: Your database schema is not in sync with your migration history.

The following is a summary of the differences between the expected database schema given your migrations files, and the actual schema of the database.

It should be understood as the set of changes to get from the expected schema to the actual schema.

[+] Added extensions
  - pg_cron

We need to reset the "public" schema at "localhost:54322"

You may use prisma migrate reset to drop the development database.
All data will be lost.
Command failed with exit code 130: /private/var/folders/1h/l7bdt8tx7c76sr7spy1ndmbh0000gn/T/xfs-20fb55b8/prisma migrate dev

The pg cron warning is something we have seen before, and I don't believe is related to the issue here, as we have been using the workaround described here for years without issue: https://github.com/prisma/prisma/issues/18214. But given the lack of any stack trace, its difficult to tell what is going wrong, as it just stops before doing anything at all. Here is 6.0.1 output:

Prisma schema loaded from schema
Datasource "db": PostgreSQL database "postgres", schema "public" at "localhost:54322"

Drift detected: Your database schema is not in sync with your migration history.

The following is a summary of the differences between the expected database schema given your migrations files, and the actual schema of the database.

It should be understood as the set of changes to get from the expected schema to the actual schema.

[+] Added extensions
  - pg_cron

? We need to reset the "public" schema at "localhost:54322"
Do you want to continue? All data will be lost. › (y/N)

Prisma schema loaded from schema
Datasource "db": PostgreSQL database "postgres", schema "public" at "localhost:54322"

Drift detected: Your database schema is not in sync with your migration history.

The following is a summary of the differences between the expected database schema given your migrations files, and the actual schema of the database.

It should be understood as the set of changes to get from the expected schema to the actual schema.

[+] Added extensions
  - pg_cron

? We need to reset the "public" schema at "localhost:54322"
Do you want to continue? All data will be lost. › (y/N)

GitHub

Issues · prisma/prisma

Next-generation ORM for Node.js & TypeScript | PostgreSQL, MySQL, MariaDB, SQL Server, SQLite, MongoDB and CockroachDB - Issues · prisma/prisma

Prisma AI Help•4/24/25, 4:25 PM

You selected to wait for the human sages. They'll share their wisdom soon.

Grab some tea while you wait, or check out

#ask-ai

#ask-ai

if you'd like a quick chat with the bot anyway!

VincentOP•4/24/25, 4:30 PM

I think this issue is related to the change described in 6.5.0 release notes here: https://github.com/prisma/prisma/releases/tag/6.5.0

GitHub

Release 6.5.0 · prisma/prisma

Today, we are excited to share the 6.5.0 stable release

Help us spread the word about Prisma by starring the repo

or tweeting about the release.

Highlights
Databases can only be reset manu...

VincentOP•4/24/25, 4:31 PM

In this version we're removing the prompt entirely and instead exiting with an appropriate error message.

But I don't get any message, and if the issue is with pg_cron now, I am sort of stuck?

Nurul•4/27/25, 3:32 PM

Hey!

I haven't seen this exit code 130 error before, so it seems new.

Does prisma migrate dev command start working again if you downgrade to prisma version 6.0.1?

VincentOP•4/29/25, 4:51 PM

6.4.1 and lower works just fine, this issue is due to the fact that in 6.5.0 there is no graceful reset available anymore when an error occurs. So in my case running reset works, but running dev produces an error that I cannot fix.

I provided more details in the open issue on pg_cron here: https://github.com/prisma/prisma/issues/18214#issuecomment-2828241685

Nurul•4/30/25, 2:19 PM

What used to happen previously? What would you usually do to workaround?
Can you share with me the steps you used to take once you got the prompt to reset the database?

VincentOP•5/1/25, 10:01 PM

Yep, it is actually quite simple

VincentOP•5/1/25, 10:01 PM

Let me see if I can capture a video of my current workflow

VincentOP•5/1/25, 10:14 PM

@Nurul here is a recording I made of what happens on my machine when I run prisma migrate dev: https://asciinema.org/a/TzMPoVDGyoZg9A9y1w3QA79Bu

asciinema.org

untitled

Recorded by vinnymac

VincentOP•5/1/25, 10:14 PM

Notice how we get the same error, but entering allows me to continue.

VincentOP•5/1/25, 10:18 PM

In the example above contains the following contents:

Which can't be committed because the extension cannot be created in the shadow db. If I run dev again I get this output:

VincentOP•5/6/25, 4:16 PM

@Nurul is there anything else I can provide to help in resolving this issue? I'd love to find a way to ignore the

pg_cron

pg_cron

extension when running

prisma migrate dev

prisma migrate dev

or even just being able to use it on or higher.

VincentOP•5/7/25, 2:19 AM

I am currently exploring a potential workaround for this issue, where I provision a secondary supabase/postgres instance as a shadow db, and use that for prisma migrations. I'll let you know if this is a good workaround for this issue...