I encountered several errors after upgrading to 22.1 with Prisma 12.1especially when using findFirst and findUnique but the issue is not limited to that.
If you happen to see some graphql errors – or even an error and then a retry success – look in your logs (ie Netlify function logs for graphql) and if you see:
ERROR Invoke Error {"errorType":"Error","errorMessage":"write EPIPE","code":"EPIPE","clientVersion":"2.12.1","stack":["Error: write EPIPE"," at PrismaClientFetcher.request (/var/task/dist/webpack:/mnt/ramdisk/project/node_modules/@prisma/client/runtime/index.js:79355:15)"," at processTicksAndRejections (internal/process/task_queues.js:97:5)"]}
and then
ERROR Uncaught Exception {"errorType":"TypeError","errorMessage":"Cannot read property 'onError' of undefined","stack":["TypeError: Cannot read property 'onError' of undefined"," at Socket.ce (/var/task/dist/webpack:/mnt/ramdisk/project/node_modules/@prisma/client/runtime/index.js:25673:45)"," at Socket.emit (events.js:314:20)"," at Socket.EventEmitter.emit (domain.js:483:12)"," at Pipe.<anonymous> (net.js:676:12)"]}
it is likely due to this issue:
What they suspect happened is:
that lambda is cleaning up the /tmp directory and cleaning up our unix domain socket which we use now in the latest version(we were using a TCP port before for Rust ↔ communication).
upgrading too "@prisma/cli": "^2.14.0-dev.68", "@prisma/client": "^2.14.0-dev.68", and adding the useUds: false seems to have fixed this issue for me as well. I’ve been using Node 12 with Postgres RDS and an RDS proxy. (previously was on ^2.13.1 of prisma cli and client)
I have still seen it with 2.14 so going to try that dev.68
Note to anyone trying to use Prisma 2.14 — it has a new migrate feature that no longer supports the db save etc and you need to use its migrate directly
And if you dont have a dev and prod env and migrate your one db there’s a chance the db will lose all data — which is perfectly fine in dev
Updating the Prisma saga: it’s 2.15 release fixes the EPIPE issue but as @pi0neerpat notes 2.13+ now has migrate dev which can make it dificult to run a cloud db like Supabase or Heroku as a dev database because with Prisma’s “shadow database” the db user must have permissions to create databases (something your Heroku user will not have). Prisma intends to addresss that issue in via this approach probably in 2.16.
That said, since moving to 2.15 I haven’t experienced the EPIPE socket issue at all.
In Prisma 2.13 they revamped their migration flow and commands.
You will have to run the new commands manually per:
That said their are some caveat as noted about:
dev shadow database is needed
beware of reseting the database (and losing data if you run the dev commands pointing the prod in some cases)
The RW team is working on a guide and transition to the new prisma migrate in the next release – and new commands that will supersedes the old db save etc.
For me though, if I did not need to make any change to the schema I simply did not run any db commands during deploy:
[build]
# Turning off migrates until migrate deploy supported
#command = "yarn rw build && yarn rw db up --no-db-client --auto-approve && yarn rw dataMigrate up"
command = "yarn rw build"
publish = "web/dist"
functions = "api/dist/functions"
So - simply build. And for this app, am running 2.15.
If you wish to still manage db ups and saves in the old manner, I suggest downgrading to Prisma 2.11.