Transaction items run outside Postgres transaction (breaks) with random order

[jgo80]

Bug description

While using the prisma.$transaction feature in 2.11.0, transaction items run outside the Postgres transaction. Also the items of the JS-Array run in totally random order instead of sequential.

How to reproduce

Sample code:

const rawQuery = prisma.$queryRaw`SELECT * FROM USER`;
const updateUsers = prisma.user.updateMany({
  where: { name: 'A' },
  data: { name: 'B' },
});

prisma.$transaction([rawQuery, updateUsers]).then(console.log).catch(console.error);

Result on first run:
The raw query is the last before commit, instead of the first after BEGIN.

prisma:query BEGIN
prisma:query SELECT "public"."User"."id" FROM "public"."User" WHERE "public"."User"."name" = $1
prisma:query UPDATE "public"."User" SET "name" = $1 WHERE "public"."User"."id" IN ($2,$3,$4,$5,$6,$7,$8)
prisma:query SELECT * FROM USER
prisma:query COMMIT

Result on next run:
Now the raw query runs even before BEGIN, outside the Postgres transaction.

prisma:query SELECT * FROM USER
prisma:query BEGIN
prisma:query SELECT "public"."User"."id" FROM "public"."User" WHERE "public"."User"."name" = $1
prisma:query UPDATE "public"."User" SET "name" = $1 WHERE "public"."User"."id" IN ($2,$3,$4,$5,$6,$7,$8)
prisma:query COMMIT

Result on any next run:

The order of the lines above appears to be totally random. Some queries even run after COMMIT.

Expected behavior

• Maintain sequential order of transactions
• Keep transactions inside BEGIN / COMMIT block

Prisma information

model User {
  id        String  @id @default(uuid())
  name      String
}

Environment & setup

• OS: Mac OS
• Database: PostgreSQL
• Node.js version: 15.2.0
• Prisma version:

@prisma/cli          : 2.11.0
@prisma/client       : 2.11.0
Current platform     : darwin
Query Engine         : query-engine 58369335532e47bdcec77a2f1e7c1fb83a463918 (at node_modules/@prisma/engines/query-engine-darwin)
Migration Engine     : migration-engine-cli 58369335532e47bdcec77a2f1e7c1fb83a463918 (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine : introspection-core 58369335532e47bdcec77a2f1e7c1fb83a463918 (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary        : prisma-fmt 58369335532e47bdcec77a2f1e7c1fb83a463918 (at node_modules/@prisma/engines/prisma-fmt-darwin)
Studio               : 0.311.0

[pantharshit00]

I can reproduce this. Thanks for the detailed reproduction.

I also double checked the query logs from postgres itself:

[pantharshit00]

Version used for reproduction:

Environment variables loaded from prisma/.env
@prisma/cli          : 2.13.0-dev.32
@prisma/client       : 2.13.0-dev.32
Current platform     : debian-openssl-1.1.x
Query Engine         : query-engine 51c23f0781ba19ff57aae049b2ea2fd4ae6b4560 (at node_modules/@prisma/engines/query-engine-debian-openssl-1.1.x)
Migration Engine     : migration-engine-cli 51c23f0781ba19ff57aae049b2ea2fd4ae6b4560 (at node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Introspection Engine : introspection-core 51c23f0781ba19ff57aae049b2ea2fd4ae6b4560 (at node_modules/@prisma/engines/introspection-engine-debian-openssl-1.1.x)
Format Binary        : prisma-fmt 51c23f0781ba19ff57aae049b2ea2fd4ae6b4560 (at node_modules/@prisma/engines/prisma-fmt-debian-openssl-1.1.x)
Studio               : 0.323.0