@janpio we running into the issue you posted 7 days ago https://github.com/prisma/prisma/issues/13396

Hi @Pieter - have you tried specifying the

binaryTarget

?

generator client {
  provider      = "prisma-client-js"
  binaryTargets = ["native", "rhel-openssl-1.0.x"]
}

binaryTargets

is indeed for the case where you develop on onr platform, but then deploy to another platform where the build might be happening on another OS than the deployment, or the deployment just zips up a deployment (like AWS Lambda function deploys do). I will reply in the issue though to ask a few follow up questions.

Sorry I was out of office so only saw this now. We did try the binary targets, the problem is that AWS lambda only allow 50mb storage and if we got more than 1 binary, we end up running over that limit. Prisma data proxy is our current scapegoat for it, but its not reliable and has caused outages in the past.

That is what it does by default (binaryTarget

native

) but that breaks for environments where you deploy an already generated Client with the binary - like on AWS Lambda. If you build/generate on a different OS than what runs on AWS Lambda, the engine file can not be correct in that case.

I think I get what is happening here. We use nx.dev which caches remotely and I think its caching the binary. We need to do a check on the OS or something to invalidate the prisma generate cached command. Then we can default to

native

and it should be all good

That sounds possible. I had 1 prior investigation around nx.dev and its caching (wasn't that even with your project? 😄) and it was not easy to figure out 😕

yep it was indeed with our project 😄 and I got it sorted. Was my .dockerignore that had node_modules in it lol

Haha, ok - that is kinda of a far reaching ignore rule 😛