Every condition on a deleteMany call is satisfied if none of the records meet the criteria

[SamSokolin]

Bug description

Recently ran into a bit of a nasty bug related to the every filter for a deleteMany call. I had a prisma deleteMany call set up like so:

const dogs = await prisma.dog.deleteMany({
    where: {
      breed: DogBreed.BEAGLE,
      owners: {
        every: {
          name: "Sam Sokolin",
        },
      },
    },
  });

and a Dog record in my database structured like so:

{
  "breed": "BEAGLE",
  "owners": [{
    "name": "John Smith"
  }]
}

I would expect that deleteMany call to be a no-op because there are no dogs with the breed “BEAGLE” where all of the owners have name “Sam Sokolin”. However, what ended up happening is that owners resulted in an empty array and the every condition was satisfied. Thus the deleteMany call attempted to delete the “John Smith”-owned dog record which failed due to a foreign key constraint. The deleteMany call was part of a transaction which was used to make updates to the Owner table and consequently every single update to the Owner table was failing, even though none of them were updating “John Smith”.
The remediation to this bug was updating the deleteMany call to be one of these two options:

// Check both every and some
prisma.dog.deleteMany({
  where: {
    breed: DogBreed.BEAGLE,
    AND: [
      {
        owners: {
          every: {
            id: "Sam Sokolin",
          },
        },
      },
      {
        owners: {
          some: {
            id: "Sam Sokolin",
          },
        },
      },
    ],
  },
})

// Check every and NOT none
prisma.dog.deleteMany({
  where: {
    breed: DogBreed.BEAGLE,
    AND: [
      {
        owners: {
          every: {
            id: "Sam Sokolin",
          },
        },
      },
      {
        NOT: {
          owners: {
            none: {
              id: "Sam Sokolin",
            },
          },
        }
      },
    ],
  },
})

To me, it feels odd that the every condition passes if NONE of the owners have the correct name. I’m not sure if this is by design, or indeed a Prisma bug, but figured it was at least worth flagging for discussion! Curious to hear thoughts!

How to reproduce

N/a

Expected behavior

The initial deleteMany call to be a no-op.

Prisma information

Redacted schema and actual code in favor of a parallel example with 🐶s. Let me know if it's unclear or needs further explanation!

Prisma version info:

prisma@^4.7.0:
  version "4.7.1"
  resolved "https://registry.yarnpkg.com/prisma/-/prisma-4.7.1.tgz#0a1beac26abdc4421e496b75eb50413f3ee3b0ba"
  integrity sha512-CCQP+m+1qZOGIZlvnL6T3ZwaU0LAleIHYFPN9tFSzjs/KL6vH9rlYbGOkTuG9Q1s6Ki5D0LJlYlW18Z9EBUpGg==
  dependencies:
    "@prisma/engines" "4.7.1"

Environment & setup

• OS: macOS
• Database: PostgreSQL
• Node.js version: v16.18.1

Prisma Version

Environment variables loaded from prisma/.env
prisma                  : 4.7.1
@prisma/client          : 4.7.1
Current platform        : darwin-arm64
Query Engine (Node-API) : libquery-engine 272861e07ab64f234d3ffc4094e32bd61775599c (at node_modules/@prisma/engines/libquery_engine-darwin-arm64.dylib.node)
Migration Engine        : migration-engine-cli 272861e07ab64f234d3ffc4094e32bd61775599c (at node_modules/@prisma/engines/migration-engine-darwin-arm64)
Introspection Engine    : introspection-core 272861e07ab64f234d3ffc4094e32bd61775599c (at node_modules/@prisma/engines/introspection-engine-darwin-arm64)
Format Binary           : prisma-fmt 272861e07ab64f234d3ffc4094e32bd61775599c (at node_modules/@prisma/engines/prisma-fmt-darwin-arm64)
Format Wasm             : @prisma/prisma-fmt-wasm 4.7.1-1.272861e07ab64f234d3ffc4094e32bd61775599c
Default Engines Hash    : 272861e07ab64f234d3ffc4094e32bd61775599c
Studio                  : 0.477.0
Preview Features        : extendedWhereUnique