Prisma Client queries are executed multiple times in `3.9.1`

Bug description

After upgrading to Prisma version 3.9.1 from version 3.8.1, Prisma started to execute transactions twice if used in a non-async function.

For example, if you have a GraphQL resolver written like this:

t.field("createBanner", {
  type: "Banner",
  args: {
    input: nonNull("BannerInput"),
  },
  resolve: (_, { input }, context) => {
    assertAccess(context, ["ADMIN"]);

    return prisma.banner.create({
      data: input,
    });
  },
});

Prisma will execute the create operation twice, resulting in duplicate entries in the database. But if rewrite this resolver with a simple change of adding async, thus making the return value an explicit Promise, then issue is resolved:

t.field("createBanner", {
  type: "Banner",
  args: {
    input: nonNull("BannerInput"),
  },
-  resolve: (_, { input }, context) => {
+  resolve: async (_, { input }, context) => {
    assertAccess(context, ["ADMIN"]);

    return prisma.banner.create({
      data: input,
    });
  },
});

How to reproduce

Use Prisma inside of a non-async function.

I’ve also recorded a reproduction of this bug. In the video recording, besides the aforementioned issue, I’ve encountered an odd problem, where I had some sort of a ghost node task hanging in the background, preventing me from restarting the dev server, but this might be unrelated to Prisma.

Expected behavior

No response

Prisma information

Relevant part of the schema.prisma

Prisma schema

model Banner {
  id          Int        @id @default(autoincrement())
  createdAt   DateTime   @default(now()) @map("created_at") @db.Timestamptz(6)
  updatedAt   DateTime   @default(now()) @updatedAt @map("updated_at") @db.Timestamptz(6)
  image       String
  mobileImage String?    @map("mobile_image")
  note        String?
  pathMatch   String     @map("path_match")
  exact       Boolean    @default(false)
  link        String?
  type        BannerType @default(TOP)
  validUntil  DateTime?  @map("valid_until") @db.Timestamptz(6)

  @@map("banners")
}

Environment & setup

• OS: macOS Monterey 12.2
• Database: PostgreSQL
• Node.js version: 16.13.1

Prisma Version

prisma                  : 3.9.1
@prisma/client          : 3.9.1
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/libquery_engine-darwin-arm64.dylib.node)
Migration Engine        : migration-engine-cli bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine    : introspection-core bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary           : prisma-fmt bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Default Engines Hash    : bcc2ff906db47790ee902e7bbc76d7ffb1893009
Studio                  : 0.457.0

[millsp]

Hey, the fix for this issue has been released via 3.9.2. Thank you for reporting this issue!

[millsp]

Thanks for the clear reproduction, I can confirm this. Apollo is doing a double call to then on the PrismaPromise which causes it to execute twice. We used to have a mechanism to prevent double execution, but that is gone. I’ll push a fix later today.