If anyone is still having trouble, for me this was related to Nx monorepo caching the .prisma directory from a previous build. These caches are not easy to spot in your directory tree.

Some quick commands to try:

To find .prisma caches

find . -name .prisma

For me this returned

./node_modules/.prisma
./node_modules/.cache/nx/4eed8695dacb1a0791560527d1349b02482e356ecd914b8f5b6a04b136d8afcc/outputs/dist/packages/app/node_modules/.prisma
./node_modules/.cache/nx/b817ddbda9e0f7f96e31d2026e51b70340b23febeef0d9b4c629ded7526f39c3/outputs/dist/packages/app/node_modules/.prisma
./node_modules/.cache/nx/3f0333ed9f8580046ca58f9c687d609aa91551c4c539e5fb442677a5bd52802e/outputs/dist/packages/app/node_modules/.prisma

Delete node_modules/.prisma and node_modules/.cache directory, and then regenerate prisma client

rm -rf node_modules/.prisma
rm -rf node_modules/.cache
npx prisma generate

Working again for me 🎉

Hey all 20+ people that reported this problem here, as you can see with the labels we still do not have a good idea why this s happening - which is required for us to fix it. And we definitely want, you all staying on 3.0.2 is a workaround, but not something that should become a long term solution.

So, let’s take another look if we can figure this out. Everyone who posted here and still has the problem, please do the following things two times. Once for your project in its working state (with whatever version that was, or 3.0.2 if you went to that) and once with a failing newer version of Prisma (either the current 3.5.0 or whatever you tried before):

1. Run npx prisma -v in your project directory and store the full output of that
2. Set the env var DEBUG=*, full instructions at https://pris.ly/d/debugging
3. Enable full logging in PrismaClient, instructions at https://pris.ly/d/logging
4. Start you application and run the problematic query. Copy all the output from your terminal and store it somewhere. (Might be quite a lot depending on your application - that is fine).

Then when you have these 2 data bits (version info and log output) for both cases, please post a comment here with the in total 4 output copies or send them to me at jan@prisma.io if you do not want to share them publicly.

While you are at it, and you are comfortable with that, please archive your full failing project (including your node_modules!) into a zip file, upload it somewhere, and send the link to me at jan@prisma.io as well. Maybe we can figure out what is going wrong by looking at the code that is actually running on your computers.

I know we are asking for a lot here, but this seems like the only way forward here and to finally hopefully be able to understand what is going on here. Thanks!

Having same issue, solved by deleting duplicated .prisma folders.

I faced the same issue. Turns out I had a .prisma folder in dist folder. After deleting the issue was fixed

@janpio no the missing .env file message did not cause the failure but probably points to the problem.

The project had two .prisma/clients one in ./node_modules and one in ./apps/node_modules which I accidentally created by running npx prisma generate in ./apps/ instead of the project root.

I can confirm that removing the second client in ./apps/ did indeed resolve my problems. But I just tried to break a working install by running npx prisma generate in ./apps, but even after a full compile the code still ran. Thus is seems that it is not a one flick switch but might involve doing other things like running npm/yarn install to change the order of package/module resolution.

But having two generated clients based on (potentially) different schemas does explain quite a few of the issues I experienced. E.g why “old” queries kept on working, but new additions not. Or why even removing models did not work as expected.

Wonder if it would be worth to ensure that the client created by prisma generate is only written in folders containing a package.json, or if it’s not present traverses up to the closest ancestor with one?

I am getting this error, here’s a minimal example, just using npm.

https://github.com/aantthony/prisma-bug

It seems to be triggered if there are two simultaneous requests to findUniqueOrThrow.

Looks like it’s fixed in 4.7.1. My example works now.

If anyone is still having trouble, for me this was related to Nx monorepo caching the .prisma directory from a previous build. These caches are not easy to spot in your directory tree.

Some quick commands to try:

To find .prisma caches

find . -name .prisma

For me this returned

./node_modules/.prisma
./node_modules/.cache/nx/4eed8695dacb1a0791560527d1349b02482e356ecd914b8f5b6a04b136d8afcc/outputs/dist/packages/app/node_modules/.prisma
./node_modules/.cache/nx/b817ddbda9e0f7f96e31d2026e51b70340b23febeef0d9b4c629ded7526f39c3/outputs/dist/packages/app/node_modules/.prisma
./node_modules/.cache/nx/3f0333ed9f8580046ca58f9c687d609aa91551c4c539e5fb442677a5bd52802e/outputs/dist/packages/app/node_modules/.prisma

Delete node_modules/.prisma and node_modules/.cache directory, and then regenerate prisma client

rm -rf node_modules/.prisma
rm -rf node_modules/.cache
npx prisma generate

Working again for me 🎉

Thanks a lot! I run find . -name .prisma and it logged

./.yarn/unplugged/@prisma-client-virtual-8a63005ea4/node_modules/.prisma
./node_modules/.prisma

so I deleted only ./.yarn/unplugged/@prisma-client-virtual-8a63005ea4/node_modules/.prisma and now it’s working again on Prisma 3.9.0.

oh my god, having the same problem now 😦

Having same issue, solved by deleting duplicated .prisma folders.

After having used 3.2.1 for a few weeks without any problems. I changed the name of one model today and since then I see the same problem for that renamed table and any other newly added model.

• I haven’t made any changes to the used packages in the last days, but made frequent changes to the schema

• Weirdly all previously existing tables remain working. Just newly added are not.

• Even, if I reduce the prisma.schema to just one new model

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

generator client {
  provider        = "prisma-client-js"
  previewFeatures = ["filterJson"]
}

model Player {
  id                 Int      @id @default(autoincrement())
  level              Int
}

a prisma db push does yield to a broken client.

• While reverting from 3.2.1 to 3.1.1 did not help, I can confirm that downgrading to 3.0.2 does solve this issue, new and old tables do work as they should.

• I’ve manually removed /node_modules/.prisma and /node_modules/@prisma/... and reinstalled the packages for 3.2.1 and 3.1.1 this did not help, and fully reset the database (as in dropping the docker container and rebuilding it).

• Upgrading the working 3.0.2 to 3.2.1 does show the same problems.

-Changing the initially changed table"s name back to the working state did not help either.

• And lastly npx prisma studio does work in 3.2.1 and 3.1.1 new and old tables are working. It’s just the the client in js

import Prisma from "@prisma/client";
const { PrismaClient } = Prisma;

that raises the error …

Is there any other cache I could clear? What is the difference between studio and JS client?

Thank you!

For me, the issue seems introduced in Prisma 3.1.1 - prisma 3.0.2 works fine.

The issue occurs when creating multiple clients, probably since you’re using a monorepo with microservices and multiple schemas.

Why

By default, prisma generates the client under node_modules/.prisma.

Since this is global, the last generated client will be used, so if you have multiple services that you want to run/test it won’t work.

A partial solution is to create a separate prisma client per service by specifying a relative path in schema.prisma:

generator client {
  provider = "prisma-client-js"
  output   = ".././.prisma/client"
}

This will create a client per service, but you have to import it explicitly instead of @prisma/client, because @prisma/client imports node_modules/.prisma/client

When using this method, the client remembers the location it was generated in, and after you build it will still use the original folder. For example, if you have apps/users/.prisma/client, and your build goes to dist/apps/users, it will still try to use the client from the first folder.

Once the application is built, the prisma client uses the apps/users folder as it’s working directory

It finds the project root / and starts searching for .prisma/client.

It uses the first client it finds using alphanumeric sorting, so if we have apps/auth/.prisma and apps/users/.prisma it will pick auth regardless of the current service.

This means the users service will use the auth client, causing Field does not exist on enclosing type.

Only the first alphanumeric service will work

A workaround is to find . -name .prisma and delete all the folders. But this means you can only run a single service at a time and clean up after it, which is not acceptible

How to fix

You need to build and develop using the same prisma path. We did this by:

• copying the prisma folder to the dist path before building

• Generate the client using npx prisma generate --schema=apps/users/prisma/schema.prisma

• Add output path to your schema (will help for jest config)

generator client {
  provider = "prisma-client-js"
  output   = "../node_modules/@db/client"
}

This will result in the following structure:

• Create a custom library to point to the prisma client in the service tsconfig.json (not the global one)

    "compilerOptions": {
        "paths": {
            "@db/client": ["dist/apps/users/node_modules/@db/client"]
        }
    }

• Modify the service jest config to track that module (not global)

moduleDirectories: ['node_modules', 'dist/apps/auth/node_modules']

Unfortunately it’s a really long workaround, but still worth it to use prisma 😃

Yes, a user before describes that cleaning up any possible .prisma packages in subfolders fixed the problem for them. This should obviously not be the case or fail in this way, but it seems it currently is.

I can also confirm this issue.

I can reproduce this with MySQL 5.7 and Prisma 3.7.0

After I run ls **/.prisma and delete all other prisma directories, it starts working again.

Also it works in 3.0.2 as mentioned in previous comments before I delete other prisma directories

I followed @novazembla instructions and added some console.log calls in ./node_modules/.prisma/client/index.js.

const dirname = findSync(process.cwd(), [
    "node_modules\\.prisma\\client",
    ".prisma\\client",
], ['d'], ['d'], 1)[0] || __dirname

console.log(__dirname);
console.log(dirname);

Got some interesting outputs, first line is the file path of client/index.js, second one is the path returned by findSync:

/home/lou/myproject/node_modules/.prisma/client
/home/lou/myproject/cdk.out/asset.17db237dbd140204955ba4b0bb83ceedc48b84e1ee73efecfbc1b83d6f620962/nodejs/node_modules/.prisma/client

This project uses AWS CDK to create an infrastructure and deploy the code on it. Binaries are bundled and cached as assets in the cdk.out folder. It’s been a long time since I built the project with CDK, and the content of that folder is clearly outdated compared to the current state of the source code.

Here is a simplified tree hierarchy for the project:

myproject/ cdk.out dist node_modules src …

I removed the cdk.out folder, and gave it another try. here are the console output results:

/home/lou/myproject/node_modules/.prisma/client
/home/lou/myproject/dist/node_modules/nodejs/node_modules/.prisma/client

Ok, findSync found another path in the dist folder this time. Luckily for me, the content of this folder is in sync with the code, and now all prisma calls pass, no more errors.

Still, I would have expected client/index.js to priorize it’s own path first.

/home/lou/myproject/node_modules/.prisma/client
/home/lou/myproject/node_modules/.prisma/client

If not found, then try a findSync and cross your fingers that the returned path makes sense.

Yes, a user before describes that cleaning up any possible .prisma packages in subfolders fixed the problem for them. This should obviously not be the case or fail in this way, but it seems it currently is.

Yes, there is a postinstall hook that generates prisma generate & also I’ve removed many fields (which requires a regenerate every time). I had a look at the debugging guide in Prisma and this was my full trace… bit massive:

event - compiled successfully
  prisma:client Prisma Client call: +1m
  prisma:client prisma.user.findUnique({
  prisma:client   where: {
  prisma:client     id: 5
  prisma:client   },
  prisma:client   select: {
  prisma:client     id: true
  prisma:client   }
  prisma:client }) +5ms
  prisma:client Generated request: +8ms
  prisma:client query {
  prisma:client   findUniqueUser(where: {
  prisma:client     id: 5
  prisma:client   }) {
  prisma:client     id
  prisma:client   }
  prisma:client }
  prisma:client  +2ms
  prisma:client:libraryEngine sending request, this.libraryStarted: true +1m
prisma:query SELECT 1
prisma:query SELECT "public"."users"."id" FROM "public"."users" WHERE "public"."users"."id" = $1 LIMIT $2 OFFSET $3
  prisma:client Prisma Client call: +129ms
  prisma:client prisma.user.update({
  prisma:client   where: {
  prisma:client     id: 5
  prisma:client   },
  prisma:client   data: {
  prisma:client     locale: 'en'
  prisma:client   }
  prisma:client }) +1ms
  prisma:client Generated request: +7ms
  prisma:client mutation {
  prisma:client   updateOneUser(
  prisma:client     where: {
  prisma:client       id: 5
  prisma:client     }
  prisma:client     data: {
  prisma:client       locale: "en"
  prisma:client     }
  prisma:client   ) {
  prisma:client     id  prisma:client     username
  prisma:client     name
  prisma:client     email
  prisma:client     emailVerified
  prisma:client     password
  prisma:client     bio
  prisma:client     avatar
  prisma:client     timeZone
  prisma:client     weekStart
  prisma:client     startTime
  prisma:client     endTime
  prisma:client     bufferTime
  prisma:client     hideBranding
  prisma:client     theme
  prisma:client     createdDate
  prisma:client     completedOnboarding
  prisma:client     locale
  prisma:client     twoFactorSecret
  prisma:client     twoFactorEnabled
  prisma:client     plan
  prisma:client   }
  prisma:client }
  prisma:client  +1ms
  prisma:client:libraryEngine sending request, this.libraryStarted: true +134ms
  prisma:client:libraryEngine graphQLToJSError +15ms
  prisma:client:fetcher Error: Failed to validate the query: `Unable to match input value to any allowed input type for the field. Parse errors: [Query parsing/validation error at `Mutation.updateOneUser.data.UserUpdateInput.locale`: Field does not exist on enclosing type., Query parsing/validation error at `Mutation.updateOneUser.data.UserUncheckedUpdateInput.locale`: Field does not exist on enclosing type.]` at `Mutation.updateOneUser.data`
  prisma:client:fetcher     at LibraryEngine.prismaGraphQLToJSError (/home/avanandel/calendso/node_modules/@prisma/client/runtime/index.js:26921:16)
  prisma:client:fetcher     at LibraryEngine.request (/home/avanandel/calendso/node_modules/@prisma/client/runtime/index.js:26938:24)
  prisma:client:fetcher     at async cb (/home/avanandel/calendso/node_modules/@prisma/client/runtime/index.js:38705:26)
  prisma:client:fetcher     at async getOrSetUserLocaleFromHeaders (webpack-internal:///./lib/core/i18n/i18n.utils.ts:45:7)
  prisma:client:fetcher     at async getServerSideProps (webpack-internal:///./pages/event-types/index.tsx:1068:18)
  prisma:client:fetcher     at async Object.renderToHTML (/home/avanandel/calendso/node_modules/next/dist/server/render.js:428:24)
  prisma:client:fetcher     at async doRender (/home/avanandel/calendso/node_modules/next/dist/server/next-server.js:1144:38)
  prisma:client:fetcher     at async /home/avanandel/calendso/node_modules/next/dist/server/next-server.js:1236:28
  prisma:client:fetcher     at async /home/avanandel/calendso/node_modules/next/dist/server/response-cache.js:64:36 +1m
event - build page: /_error
wait  - compiling...
event - compiled successfully
11:22:27.513 timeZoneName DEBUG [error] server side logged this: Error: 
Invalid `prisma.user.update()` invocation:


  Failed to validate the query: `Unable to match input value to any allowed input type for the field. Parse errors: [Query parsing/validation error at `Mutation.updateOneUser.data.UserUpdateInput.locale`: Field does not exist on enclosing type., Query parsing/validation error at `Mutation.updateOneUser.data.UserUncheckedUpdateInput.locale`: Field does not exist on enclosing type.]` at `Mutation.updateOneUser.data` 
11:22:27.524 timeZoneName INFO [error] return props,  
{
  statusCode: 500,
  hasGetInitialPropsRun: true
}
11:22:27.573 timeZoneName DEBUG [error] server side logged this: Error: 
Invalid `prisma.user.update()` invocation:


  Failed to validate the query: `Unable to match input value to any allowed input type for the field. Parse errors: [Query parsing/validation error at `Mutation.updateOneUser.data.UserUpdateInput.locale`: Field does not exist on enclosing type., Query parsing/validation error at `Mutation.updateOneUser.data.UserUncheckedUpdateInput.locale`: Field does not exist on enclosing type.]` at `Mutation.updateOneUser.data` 
11:22:27.579 timeZoneName INFO [error] return props,  
{
  statusCode: 500,
  hasGetInitialPropsRun: true
}
error - PrismaClientKnownRequestError: 
Invalid `prisma.user.update()` invocation:


  Failed to validate the query: `Unable to match input value to any allowed input type for the field. Parse errors: [Query parsing/validation error at `Mutation.updateOneUser.data.UserUpdateInput.locale`: Field does not exist on enclosing type., Query parsing/validation error at `Mutation.updateOneUser.data.UserUncheckedUpdateInput.locale`: Field does not exist on enclosing type.]` at `Mutation.updateOneUser.data`
    at cb (/home/avanandel/calendso/node_modules/@prisma/client/runtime/index.js:38735:17)
    at async getOrSetUserLocaleFromHeaders (webpack-internal:///./lib/core/i18n/i18n.utils.ts:45:7)
    at async getServerSideProps (webpack-internal:///./pages/event-types/index.tsx:1068:18)
    at async Object.renderToHTML (/home/avanandel/calendso/node_modules/next/dist/server/render.js:428:24)
    at async doRender (/home/avanandel/calendso/node_modules/next/dist/server/next-server.js:1144:38)
    at async /home/avanandel/calendso/node_modules/next/dist/server/next-server.js:1236:28
    at async /home/avanandel/calendso/node_modules/next/dist/server/response-cache.js:64:36 {
  code: 'P2009',
  clientVersion: '3.2.1',
  meta: {
    query_validation_error: 'Unable to match input value to any allowed input type for the field. Parse errors: [Query parsing/validation error at `Mutation.updateOneUser.data.UserUpdateInput.locale`: Field does not exist on enclosing type., Query parsing/validation error at `Mutation.updateOneUser.data.UserUncheckedUpdateInput.locale`: Field does not exist on enclosing type.]',
    query_position: 'Mutation.updateOneUser.data'
  },
  page: '/event-types'
}

@janpio I’m going to dive deeper into this now, but this is the same issue I’m experiencing on the Calendso / Cal.com project @ https://github.com/calendso/calendso when I upgrade to Prisma 3 (3.2.1) - without any code changes I am greeted with: Failed to validate the query: Field does not exist on enclosing type. at Query.findUniqueUser.User.locale. This is on what I consider a exceedingly simple findUnique query:

    const user = await prisma.user.findUnique({
      where: {
        id: session.user.id,
      },
      select: {
        locale: true,
      },
    });

Keeping you updated, but if you’re interested in seeing it crash yourself is: just checkout main and update prisma to 3.

@janpio I have been battling with this for a while. I am not sure how to reproduce this.

I went back to 3.0.2, and it all works now.

With 3.1.1 I didnt get it to work, even if I deleted all tables, prisma, prisma folder… etc. And for now I will not update for a while, I got to much to do on other parts.

Hi all, I’m also faced this issue when using .findUniqueOrThrow on version 4.7.0. Downgrade to version 4.6.1 to fix.

Not sure if it help in something but n my case it is happening when I execute a plain node application with the full path, in the currency app directory if I execute node app.js it works, but when calling node /path/to/app.js I got this error

I found a predictable way of producing multiple .prisma folders within a yarn or pnpm monorepo. Given the following structure:

/package.json
/node_modules
/packages/package-1/package.json
/packages/package-1/node_modules

package-1 is a package of the monorepo and depends on prisma and @prisma/client

1. run pnpm -r prisma generate in /

# .prisma-directories:
/node_modules/.prisma

1. run pnpm prisma generate in /packages/package-1

# .prisma-directories:
/node_modules/.prisma
/node_modules/package-1/node_modules/.prisma

Conclusion

.prisma-directory is created in the node_modules folder, which is closest to the working directory which was used when executing the pnpm/yarn run command.

Expected

Created in the node_modules folder which is closest to the actual package directory

This might cause some of these issues. At least it’s causing issues with type checking in a monorepo and the developer has to make sure to always cd packages/package-1 before using the prisma cli. As removing duplicate .prisma-folders seems to fix the issue in OP, maybe this could be the cause?

UPDATE: sorry, submitted too early by accident. Happy to provide a repo which reproduces this or open another issue if it turns out to be unrelated

I was able to create a reproduction for postgres in this repo: https://github.com/matthewmueller/prisma-ra

It’s an oddball, but it seems path-related.

Environment variables loaded from .env
prisma                  : 3.7.0
@prisma/client          : 3.7.0
Current platform        : darwin
Query Engine (Node-API) : libquery-engine 8746e055198f517658c08a0c426c7eec87f5a85f (at node_modules/@prisma/engines/libquery_engine-darwin.dylib.node)
Migration Engine        : migration-engine-cli 8746e055198f517658c08a0c426c7eec87f5a85f (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine    : introspection-core 8746e055198f517658c08a0c426c7eec87f5a85f (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary           : prisma-fmt 8746e055198f517658c08a0c426c7eec87f5a85f (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash    : 8746e055198f517658c08a0c426c7eec87f5a85f
Studio                  : 0.445.0

@janpio what you need to do is the following

1. Create a project with a prisma.schema and run prisma db push or prisma generate in the project root
2. Have a little test script that runs a findMany on one of the models to see all works well
3. Create a subfolder that will be listed before node_modules (apps, code, you name it, let’s use apps)
4. cd into apps and run prisma generate
5. Add a new model to the schema and run prisma db push in the project’s root folder
6. Add a findMany query for the new model in the test script
7. Run the script and see that the newly added findMany fails with the above error message.
8. Rename the apps folder to xapps
9. Run the script and see that the root folder’s prisma client is now been used and therefore both findMany queries are working as they should
10. Rename the xapps folder to apps
11. Run the script and see that the newly added findMany fails with the above error message. GOTO 7 😃

Obviously you could also remove apps/node_modules and see that the new version is working.

@janpio I believe if you cd in to any folder in a prisma project, and run yarn prisma generate it will create a new node_modules with your .prisma folder. This folder will then end up being the one referenced instead of the “true” root node_modules .prisma folder.

Unsure if that was your request.

Curious thing… nvm use v14.17.4 (not facing this issue) / nvm use v14.17.5 (this issue started happening)

Maybe this helps someone

Oh, sorry, I missed some context here. Yeah, if it’s running the correct client in both cases and doesn’t run the outdated client, doesn’t mix the client and the Query Engine from different directories, etc, then I’m not sure why that happens. (FWIW, I don’t know what exactly would go wrong in that case either, it just sounds like something likely to break).

P.S. In any case it would probably uber-useful if the debug log would spit out the loaded schema path and maybe the root env path. It certainly would have helped me spot the problem sooner.

@hmica that exactly been it! Sure enough there was a stub in the ./apps/ subfolder and once removed the broken branch has been revived to working order. This also explains why the broken version was assuming that ./apps/ is the root and tried to load the .env from there.

Hi, I just past my entire day on this one. I found that if I run yarn prisma generate from a sub directory it will generate stub in that sub directory

with .prisma/client on /home/user/work/my-project/my-sub-folder/node_modules/

but if I run

npx prisma generate from that subdirectory it will complain that it can not find the prisma.schema file so it’s safer.

So be sure that you don’t have .prisma/client duplication.

error logs are as follows.

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

prisma:loadEnv project root found at /Users/odyss/works/nest-serverless/package.json +0ms
  prisma:tryLoadEnv Environment variables loaded from /Users/odyss/works/nest-serverless/.env +0ms
Environment variables loaded from .env
  prisma:engines binaries to download libquery-engine, migration-engine, introspection-engine, prisma-fmt +0ms
  prisma:migrate:seed {
  prisma:migrate:seed   prismaConfig: {
  prisma:migrate:seed     data: { seed: 'ts-node prisma/seed.ts' },
  prisma:migrate:seed     packagePath: '/Users/odyss/works/nest-serverless/package.json'
  prisma:migrate:seed   }
  prisma:migrate:seed } +0ms
Running seed command `ts-node prisma/seed.ts` ...
  prisma:tryLoadEnv Environment variables loaded from /Users/odyss/works/nest-serverless/.serverless/tmp/.env +0ms
  prisma:tryLoadEnv Environment variables loaded from /Users/odyss/works/nest-serverless/.serverless/tmp/.env +4ms
  prisma:client clientVersion: 3.6.0 +0ms
  prisma:client clientEngineType: library +0ms
  prisma:client:libraryEngine internalSetup +0ms
  prisma:client Prisma Client call: +51ms
  prisma:client prisma.user.upsert({
  prisma:client   where: {
  prisma:client     email: 'alice@prisma.io'
  prisma:client   },
  prisma:client   update: {
  prisma:client     name: 'updated Alice'
  prisma:client   },
  prisma:client   create: {
  prisma:client     email: 'alice@prisma.io',
  prisma:client     name: 'alice',
  prisma:client     password: '9a38ca920c60e6d6bdc8ca3110fe5672bffa63793afccc9431f927638ed33faae1213ef5ecdbb40e8842cb2ac517920bb018d3fd997afae5c9039a4e43846450',
  prisma:client     salt: '78b3aca7c3aecb6038ac83dd4e5d322a',
  prisma:client     posts: {
  prisma:client       create: {
  prisma:client         title: 'Check out Prisma with Next.js',
  prisma:client         content: 'https://www.prisma.io/nextjs',
  prisma:client         published: true
  prisma:client       }
  prisma:client     },
  prisma:client     birthYear: 2001
  prisma:client   }
  prisma:client }) +2ms
  prisma:client Generated request: +0ms
  prisma:client mutation {
  prisma:client   upsertOneUser(
  prisma:client     where: {
  prisma:client       email: "alice@prisma.io"
  prisma:client     }
  prisma:client     update: {
  prisma:client       name: "updated Alice"
  prisma:client     }
  prisma:client     create: {
  prisma:client       email: "alice@prisma.io"
  prisma:client       name: "alice"
  prisma:client       password: "9a38ca920c60e6d6bdc8ca3110fe5672bffa63793afccc9431f927638ed33faae1213ef5ecdbb40e8842cb2ac517920bb018d3fd997afae5c9039a4e43846450"
  prisma:client       salt: "78b3aca7c3aecb6038ac83dd4e5d322a"
  prisma:client       posts: {
  prisma:client         create: {
  prisma:client           title: "Check out Prisma with Next.js"
  prisma:client           content: "https://www.prisma.io/nextjs"
  prisma:client           published: true
  prisma:client         }
  prisma:client       }
  prisma:client       birthYear: 2001
  prisma:client     }
  prisma:client   ) {
  prisma:client     id
  prisma:client     email
  prisma:client     password
  prisma:client     salt
  prisma:client     name
  prisma:client     socialRoute
  prisma:client     createdAt
  prisma:client     updatedAt
  prisma:client     birthYear
  prisma:client     duedatedAt
  prisma:client   }
  prisma:client }
  prisma:client  +0ms
  prisma:client:libraryEngine sending request, this.libraryStarted: false +53ms
  prisma:client:libraryEngine Search for Query Engine Library in /Users/odyss/works/nest-serverless/node_modules/.prisma/client +1ms
  prisma:client:libraryEngine loadEngine using /Users/odyss/works/nest-serverless/node_modules/.prisma/client/libquery_engine-darwin.dylib.node +0ms
  prisma:client:libraryEngine library starting +21ms
prisma:info Starting a mysql pool with 13 connections.
  prisma:client:libraryEngine library started +16ms
  prisma:client:fetcher Error: Failed to validate the query: `Unable to match input value to any allowed input type for the field. Parse errors: [Query parsing/validation error at `Mutation.upsertOneUser.create.UserCreateInput.birthYear`: Field does not exist on enclosing type., Query parsing/validation error at `Mutation.upsertOneUser.create.UserUncheckedCreateInput.birthYear`: Field does not exist on enclosing type.]` at `Mutation.upsertOneUser.create`
  prisma:client:fetcher     at prismaGraphQLToJSError (/Users/odyss/works/nest-serverless/node_modules/@prisma/client/runtime/index.js:35956:12)
  prisma:client:fetcher     at Object.request (/Users/odyss/works/nest-serverless/node_modules/@prisma/client/runtime/index.js:36319:17)
  prisma:client:fetcher     at cb (/Users/odyss/works/nest-serverless/node_modules/@prisma/client/runtime/index.js:38653:26)
  prisma:client:fetcher     at main (/Users/odyss/works/nest-serverless/prisma/seed.ts:11:3) +0ms
PrismaClientKnownRequestError: 
Invalid `prisma.user.upsert()` invocation:


  Failed to validate the query: `Unable to match input value to any allowed input type for the field. Parse errors: [Query parsing/validation error at `Mutation.upsertOneUser.create.UserCreateInput.birthYear`: Field does not exist on enclosing type., Query parsing/validation error at `Mutation.upsertOneUser.create.UserUncheckedCreateInput.birthYear`: Field does not exist on enclosing type.]` at `Mutation.upsertOneUser.create`
    at cb (/Users/odyss/works/nest-serverless/node_modules/@prisma/client/runtime/index.js:38683:17)
    at main (/Users/odyss/works/nest-serverless/prisma/seed.ts:11:3) {
  code: 'P2009',
  clientVersion: '3.6.0',
  meta: {
    query_validation_error: 'Unable to match input value to any allowed input type for the field. Parse errors: [Query parsing/validation error at `Mutation.upsertOneUser.create.UserCreateInput.birthYear`: Field does not exist on enclosing type., Query parsing/validation error at `Mutation.upsertOneUser.create.UserUncheckedCreateInput.birthYear`: Field does not exist on enclosing type.]',
    query_position: 'Mutation.upsertOneUser.create'
  }
}
  prisma:client:libraryEngine hookProcess received: exit +9ms
  prisma:client:libraryEngine runBeforeExit +0ms
  prisma:migrate:seed {
  prisma:migrate:seed   e: Error: Command failed with exit code 1: ts-node prisma/seed.ts
  prisma:migrate:seed       at makeError (/Users/odyss/works/nest-serverless/node_modules/prisma/build/index.js:2977:17)
  prisma:migrate:seed       at handlePromise (/Users/odyss/works/nest-serverless/node_modules/prisma/build/index.js:3704:33)
  prisma:migrate:seed       at runMicrotasks (<anonymous>)
  prisma:migrate:seed       at processTicksAndRejections (internal/process/task_queues.js:93:5)
  prisma:migrate:seed       at async executeSeedCommand (/Users/odyss/works/nest-serverless/node_modules/prisma/build/index.js:102506:5)
  prisma:migrate:seed       at async Object.parse (/Users/odyss/works/nest-serverless/node_modules/prisma/build/index.js:104010:31)
  prisma:migrate:seed       at async main (/Users/odyss/works/nest-serverless/node_modules/prisma/build/index.js:106401:18) {
  prisma:migrate:seed     shortMessage: 'Command failed with exit code 1: ts-node prisma/seed.ts',
  prisma:migrate:seed     command: 'ts-node prisma/seed.ts',
  prisma:migrate:seed     escapedCommand: 'ts-node "prisma/seed.ts"',
  prisma:migrate:seed     exitCode: 1,
  prisma:migrate:seed     signal: undefined,
  prisma:migrate:seed     signalDescription: undefined,
  prisma:migrate:seed     stdout: undefined,
  prisma:migrate:seed     stderr: undefined,
  prisma:migrate:seed     failed: true,
  prisma:migrate:seed     timedOut: false,
  prisma:migrate:seed     isCanceled: false,
  prisma:migrate:seed     killed: false
  prisma:migrate:seed   }
  prisma:migrate:seed } +3s

An error occured while running the seed command:
Error: Command failed with exit code 1: ts-node prisma/seed.ts

@aqrln @janpio

Hey guys, please find my logs below. While generating this one I noticed a difference between the working and the non working versions. Although the code base is the same the broken version tries to load the environment variables from a different folder and fails to do so…

Non working

DEBUG=* node packages/api/dist/scripts/base.js 
prisma:tryLoadEnv Environment variables not found at /Users/dev/broken-monorepo/apps/.env +0ms

Working:

DEBUG=* node packages/api/dist/scripts/base.js 
prisma:tryLoadEnv Environment variables loaded from /Users/dev/monorepo/.env 

It’s a monorepo using the following workspace definition

"workspaces": [
    "packages/*",
    "apps/*"
  ],

Does the broken version assume that the project root is /apps/? Could this cause the issues?

Anyhow, here is the full dump of the non working version.

npx prisma -v

Environment variables loaded from .env
prisma                  : 3.4.1
@prisma/client          : 3.4.1
Current platform        : darwin
Query Engine (Node-API) : libquery-engine 57771c0558568c7d08bd34c7248af5244ae16bd9 (at node_modules/@prisma/engines/libquery_engine-darwin.dylib.node)
Migration Engine        : migration-engine-cli 57771c0558568c7d08bd34c7248af5244ae16bd9 (at node_modules/@prisma/engines/migration-engine-darwin)
Introspection Engine    : introspection-core 57771c0558568c7d08bd34c7248af5244ae16bd9 (at node_modules/@prisma/engines/introspection-engine-darwin)
Format Binary           : prisma-fmt 57771c0558568c7d08bd34c7248af5244ae16bd9 (at node_modules/@prisma/engines/prisma-fmt-darwin)
Default Engines Hash    : 57771c0558568c7d08bd34c7248af5244ae16bd9
Studio                  : 0.438.0
Preview Features        : filterJson

DEBUG="*" node packages/api/dist/scripts/base.js 
  prisma:tryLoadEnv Environment variables not found at /Users/dev/monorepo/apps/.env +0ms
  prisma:tryLoadEnv Environment variables not found at /Users/dev/monorepo/apps/.env +1ms
  prisma:tryLoadEnv No Environment variables loaded +0ms
winston:create-logger: Define prototype method for "error"
winston:create-logger: Define prototype method for "warn"
winston:create-logger: Define prototype method for "info"
winston:create-logger: Define prototype method for "http"
winston:create-logger: Define prototype method for "verbose"
winston:create-logger: Define prototype method for "debug"
winston:create-logger: Define prototype method for "silly"
winston:create-logger: Define prototype method for "error"
winston:create-logger: Define prototype method for "warn"
winston:create-logger: Define prototype method for "info"
winston:create-logger: Define prototype method for "http"
winston:create-logger: Define prototype method for "debug"
  prisma:tryLoadEnv Environment variables not found at /Users/dev/monorepo/apps/.env +397ms
  prisma:tryLoadEnv Environment variables not found at /Users/dev/monorepo/apps/.env +0ms
  prisma:tryLoadEnv No Environment variables loaded +0ms
  prisma:client clientVersion: 3.4.1 +0ms
  prisma:client:libraryEngine internalSetup +0ms
  prisma:client Prisma Client call: +9ms
  prisma:client prisma.event.findMany({
  prisma:client   where: {
  prisma:client     lastEventDate: {
  prisma:client       gt: '2021-12-01T23:00:00.000Z'
  prisma:client     }
  prisma:client   },
  prisma:client   orderBy: [
  prisma:client     {
  prisma:client       firstEventDate: 'asc'
  prisma:client     },
  prisma:client     {
  prisma:client       title_de: 'asc'
  prisma:client     }
  prisma:client   ],
  prisma:client   select: {
  prisma:client     dates: {
  prisma:client       select: {
  prisma:client         date: true,
  prisma:client         begin: true,
  prisma:client         end: true
  prisma:client       }
  prisma:client     }
  prisma:client   }
  prisma:client }) +1ms
  prisma:client Generated request: +0ms
  prisma:client query {
  prisma:client   findManyEvent(
  prisma:client     where: {
  prisma:client       lastEventDate: {
  prisma:client         gt: "2021-12-01T23:00:00.000Z"
  prisma:client       }
  prisma:client     }
  prisma:client     orderBy: [
  prisma:client       {
  prisma:client         firstEventDate: asc
  prisma:client       },
  prisma:client       {
  prisma:client         title_de: asc
  prisma:client       }
  prisma:client     ]
  prisma:client   ) {
  prisma:client     dates {
  prisma:client       date
  prisma:client       begin
  prisma:client       end
  prisma:client     }
  prisma:client   }
  prisma:client }
  prisma:client  +0ms
  prisma:client:libraryEngine sending request, this.libraryStarted: false +10ms
  prisma:client:libraryEngine Search for Query Engine Library in /Users/dev/monorepo/node_modules/.prisma/client +0ms
  prisma:client:libraryEngine loadEngine using /Users/dev/monorepo/node_modules/.prisma/client/libquery_engine-darwin.dylib.node +0ms
  prisma:client:libraryEngine library starting +14ms
winston:file: stat done: error.log { size: 214604 }
winston:file: create stream start logs/error.log { flags: 'a' }
winston:file: create stream ok logs/error.log
winston:file: _incFile info.log
prisma:info Starting a postgresql pool with 1 connections.
winston:file: file open ok logs/error.log
winston:file: stat done: info1.log { size: 721938 }
winston:file: create stream start logs/info1.log { flags: 'a' }
winston:file: create stream ok logs/info1.log
winston:file: file open ok logs/info1.log
  prisma:client:libraryEngine library started +38ms
  prisma:client:libraryEngine graphQLToJSError +1ms
  prisma:client:fetcher Error: Failed to validate the query: `Field does not exist on enclosing type.` at `Query.findManyEvent.where.EventWhereInput.lastEventDate`
  prisma:client:fetcher     at Object.prismaGraphQLToJSError (/Users/dev/monorepo/node_modules/@prisma/client/runtime/index.js:36308:14)
  prisma:client:fetcher     at Object.request (/Users/dev/monorepo/node_modules/@prisma/client/runtime/index.js:36325:22)
  prisma:client:fetcher     at async cb (/Users/dev/monorepo/node_modules/@prisma/client/runtime/index.js:38474:26) +0ms
PrismaClientKnownRequestError: 
Invalid `prisma.event.findMany()` invocation:


  Failed to validate the query: `Field does not exist on enclosing type.` at `Query.findManyEvent.where.EventWhereInput.lastEventDate`
    at cb (/Users/dev/monorepo/node_modules/@prisma/client/runtime/index.js:38504:17) {
  code: 'P2009',
  clientVersion: '3.4.1',
  meta: {
    query_validation_error: 'Field does not exist on enclosing type.',
    query_position: 'Query.findManyEvent.where.EventWhereInput.lastEventDate'
  }
}
  prisma:client:libraryEngine library stopping +9ms
  prisma:client:libraryEngine library stopped +11ms
  prisma:client:libraryEngine hookProcess received: exit +0ms
  prisma:client:libraryEngine runBeforeExit +0ms

And for comparison the working version’s debug output

DEBUG=* node packages/api/dist/scripts/base.js 
  prisma:tryLoadEnv Environment variables loaded from /Users/dev/monorepo/.env +0ms
[dotenv][DEBUG] did not match key and value when parsing line 4: 
[dotenv][DEBUG] ... many more dotenv related lines
[dotenv][DEBUG] did not match key and value when parsing line 12: 
winston:create-logger: Define prototype method for "error"
winston:create-logger: Define prototype method for "warn"
winston:create-logger: Define prototype method for "info"
winston:create-logger: Define prototype method for "http"
winston:create-logger: Define prototype method for "verbose"
winston:create-logger: Define prototype method for "debug"
winston:create-logger: Define prototype method for "silly"
winston:create-logger: Define prototype method for "error"
winston:create-logger: Define prototype method for "warn"
winston:create-logger: Define prototype method for "info"
winston:create-logger: Define prototype method for "http"
winston:create-logger: Define prototype method for "debug"
  prisma:tryLoadEnv Environment variables loaded from /Users/dev/monorepo/.env +824ms
[dotenv][DEBUG] "DEV_FRONTEND_PORT" is already defined in `process.env` and will not be overwritten
[dotenv][DEBUG] ... many more dotenv related lines
[dotenv][DEBUG] "JWT_SECRET" is already defined in `process.env` and will not be overwritten
  prisma:client clientVersion: 3.4.1 +0ms
  prisma:client:libraryEngine internalSetup +0ms
  prisma:client Prisma Client call: +10ms
  prisma:client prisma.event.findMany({
  prisma:client   where: {
  prisma:client     lastEventDate: {
  prisma:client       gt: '2021-12-01T23:00:00.000Z'
  prisma:client     }
  prisma:client   },
  prisma:client   orderBy: [
  prisma:client     {
  prisma:client       firstEventDate: 'asc'
  prisma:client     },
  prisma:client     {
  prisma:client       title_de: 'asc'
  prisma:client     }
  prisma:client   ],
  prisma:client   select: {
  prisma:client     dates: {
  prisma:client       select: {
  prisma:client         date: true,
  prisma:client         begin: true,
  prisma:client         end: true
  prisma:client       }
  prisma:client     }
  prisma:client   }
  prisma:client }) +1ms
  prisma:client Generated request: +0ms
  prisma:client query {
  prisma:client   findManyEvent(
  prisma:client     where: {
  prisma:client       lastEventDate: {
  prisma:client         gt: "2021-12-01T23:00:00.000Z"
  prisma:client       }
  prisma:client     }
  prisma:client     orderBy: [
  prisma:client       {
  prisma:client         firstEventDate: asc
  prisma:client       },
  prisma:client       {
  prisma:client         title_de: asc
  prisma:client       }
  prisma:client     ]
  prisma:client   ) {
  prisma:client     dates {
  prisma:client       date
  prisma:client       begin
  prisma:client       end
  prisma:client     }
  prisma:client   }
  prisma:client }
  prisma:client  +0ms
  prisma:client:libraryEngine sending request, this.libraryStarted: false +11ms
  prisma:client:libraryEngine Search for Query Engine Library in /Users/dev/monorepo/node_modules/.prisma/client +1ms
  prisma:client:libraryEngine loadEngine using /Users/dev/monorepo/node_modules/.prisma/client/libquery_engine-darwin.dylib.node +0ms
  prisma:client:libraryEngine library starting +24ms
winston:file: stat done: error.log { size: 17066 }
winston:file: create stream start logs/error.log { flags: 'a' }
winston:file: create stream ok logs/error.log
winston:file: stat done: info.log { size: 425010 }
winston:file: create stream start logs/info.log { flags: 'a' }
winston:file: create stream ok logs/info.log
prisma:info Starting a postgresql pool with 1 connections.
winston:file: file open ok logs/error.log
winston:file: file open ok logs/info.log
  prisma:client:libraryEngine library started +42ms
prisma:query SELECT "public"."Event"."id" FROM "public"."Event" WHERE "public"."Event"."lastEventDate" > $1 ORDER BY "public"."Event"."firstEventDate" ASC, "public"."Event"."title_de" ASC OFFSET $2
prisma:query SELECT "public"."EventDate"."id", "public"."EventDate"."date", "public"."EventDate"."begin", "public"."EventDate"."end", "public"."EventDate"."eventId" FROM "public"."EventDate" WHERE "public"."EventDate"."eventId" IN ($1,$2,$3,$4,$5,$6,$7,$8,$9,$10,$11,$12,$13,$14,$15,$16,$17,$18,$19,$20,$21,$22,$23,$24,$25,$26) OFFSET $27
... here I would log the events to the console [{...}]
  prisma:client:libraryEngine library stopping +56ms
  prisma:client:libraryEngine library stopped +10ms
  prisma:client:libraryEngine hookProcess received: exit +0ms
  prisma:client:libraryEngine runBeforeExit +0ms

I solved the issue for me:

1. Uninstall prisma and @prisma/client
2. Re-install both packages
3. Run npx prisma generate

🎉 It’s working (for me at least)

I have the same issue here with prisma 3.5.0, on Windows 10. Rolling back to 3.0.2 fixes the issue. Performing a findMany on all models, only one of them throws an error:

query_validation_error: 'Field does not exist on enclosing type.',
query_position: 'Query.findManyRequest.where.RequestWhereInput.OR.RequestWhereInput.authorId'

I have two macs, M1 and Intel. M1 has no problem with any version of prisma(3.0. 3.3, 3.4). But Intel has this ‘Field does not exist on enclosing type’ error. So I had to downgrade to 3.0.2.