Prisma Client: `.count` does not work with where

Bug description

When passing the where to prisma.relation.count, the parameters are not considered, as if they had not been passed

How to reproduce

The code

console.log('query without where')

const c = await prisma.user.count()

console.log(`response: ${c}\n\n`)

console.log('query with where id = 1')

const d = await prisma.user.count({
  where: {
    id: 1
  }
})

console.log(`response: ${d}`)

The result

query without where
prisma:info Starting a postgresql pool with 5 connections.
prisma:query SELECT COUNT(*) FROM (SELECT "public"."users"."id" FROM "public"."users" WHERE 1=1 OFFSET $1) AS "sub"
response: 24


query with where id = 1
prisma:query SELECT COUNT(*) FROM (SELECT "public"."users"."id" FROM "public"."users" WHERE 1=1 OFFSET $1) AS "sub"
response: 24

Expected behavior

No response

Prisma information

They are in “How to reproduce”

Environment & setup

• OS: KDE neon 5.23
• Database: PostgreSQL 13.3
• Node.js version: v16.13.2

Prisma Version

prisma                  : 3.9.0
@prisma/client          : 3.9.0
Current platform        : debian-openssl-1.1.x
Query Engine (Node-API) : libquery-engine bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/libquery_engine-debian-openssl-1.1.x.so.node)
Migration Engine        : migration-engine-cli bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/migration-engine-debian-openssl-1.1.x)
Introspection Engine    : introspection-core bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/introspection-engine-debian-openssl-1.1.x)
Format Binary           : prisma-fmt bcc2ff906db47790ee902e7bbc76d7ffb1893009 (at node_modules/@prisma/engines/prisma-fmt-debian-openssl-1.1.x)
Default Engines Hash    : bcc2ff906db47790ee902e7bbc76d7ffb1893009
Studio                  : 0.457.0

[icflorescu]

This is actually pretty bad, I wonder how it passed the tests and ended up being published 😐

[millsp]

Sounds like a great opportunity to beef up tests

Definitely, this has clearly shown that some areas were under-tested. The next steps will be to build a more robust testing setup and we will start porting existing tests (reviewing and potentially upgrading) into this new folder. Work is starting this sprint.