Vincent Posts - Answer Overflow

Vincent

•Created by Vincent on 4/24/2025 in #help-and-questions

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 and then run 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)

7 replies

PPrisma

•Created by Vincent on 2/12/2025 in #help-and-questions

Silent and Stalled transaction

This is a strange one. I have a transaction running in a child process (worker). The transaction uses a temporary table to insert a bunch of ids to do an efficient join on a very large dataset. The code for this looks something like:

const remoteIdsSql = ids.map((id) => Prisma.sql`(${id})`);
const postgresDriverParamLimit = 32767;
const results = await this.db.$transaction(
  async (tx) => {
    await tx.$executeRaw`
      CREATE TEMP TABLE
        "temp_remote_ids" (
          "id" VARCHAR(200) PRIMARY KEY
        )
      ON COMMIT DROP`;

    for (const idsSqlChunk of chunkGenerator(idsSqlArray, postgresDriverParamLimit)) {
      await tx.$executeRaw`
        INSERT INTO
          "temp_remote_ids" ("id")
        VALUES
          ${Prisma.join(idsSqlChunk)}`;
    }

    const people = await tx.$queryRaw<People[]>`
      SELECT
        p.*
      FROM
        public."People" p
      INNER JOIN
        "temp_remote_ids" t ON p."id" = t."id"`;

    return people;
  },
  {
    timeout: 30000,
  },
);

const remoteIdsSql = ids.map((id) => Prisma.sql`(${id})`);
const postgresDriverParamLimit = 32767;
const results = await this.db.$transaction(
  async (tx) => {
    await tx.$executeRaw`
      CREATE TEMP TABLE
        "temp_remote_ids" (
          "id" VARCHAR(200) PRIMARY KEY
        )
      ON COMMIT DROP`;

    for (const idsSqlChunk of chunkGenerator(idsSqlArray, postgresDriverParamLimit)) {
      await tx.$executeRaw`
        INSERT INTO
          "temp_remote_ids" ("id")
        VALUES
          ${Prisma.join(idsSqlChunk)}`;
    }

    const people = await tx.$queryRaw<People[]>`
      SELECT
        p.*
      FROM
        public."People" p
      INNER JOIN
        "temp_remote_ids" t ON p."id" = t."id"`;

    return people;
  },
  {
    timeout: 30000,
  },
);

When I am running Prisma 6.0.1, I have no problems, the query runs just fine, no issues whatsoever. But if I upgrade to 6.1.0 or higher the worker stalls, and the query never completes. It is as if the transaction is failing silently. I have no errors in my logs, and my process analytics indicate the workers are still active, but no work is being completed. I have spent a lot of time trying to figure out what could possibly be going on here. I don't have a small reproduction to share, as this is a large project I am working on. My current theory is that this has something to do with Alpine 3.20, Prisma 6.0.1, and transactions. I have tried changing telemetry packages, downgrading @prisma/instrumentation, and upgrading Alpine to no avail. Any advice or even outlandish ideas would be appreciated here Thank you

14 replies

Gaming

Programming