RedwoodJS 22.1 and Prisma 12.1 Workaround for Intermittent: write EPIPE error

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).

The workaround is to configure your Prisma client as:

export const db = new PrismaClient({
  __internal: {
    useUds: false,
  }
})

If you are getting this behavior, I recommend setting this workaround as – so far – my app is behaving much much better at the moment.

I will update here if I see the issue return.

3 Likes

BTW - This issue may not be resolved in Prisma 14 or 15

So, perhaps this workaround may need to get into crwa?

1 Like

Oh my. Huge thanks for recording this and providing all the workaround help @dthyresson :rocket:

There’s an update from Prisma in

First, this *might * help:

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

But also

And

Looks like 2.15 may introduce an “engineMode” and default back to TCP.

2 Likes

Just an update to say that 2.14.0-dev.68 and the

export const db = new PrismaClient({
  __internal: {
    useUds: false,
  }
})

fix seems more stable than just 2.14.0. Nothing certain, but I upgraded an app to 2.14.0 and saw the same EPIPE error within a few minutes.

So far so good with 2.14.0-dev.68.

Perhaps RW should leap to 2.15 in its next release and skip 13 and 14.0.

1 Like

Omg thank you so much for this fix! I was completely dead in the water - app crashing on every other load.

Tell me about it - so frustrating. And it was completely intermittent.

Hopefully Prisma figures it out in 2.15 – but at least sticking with the TCP engine seems to be the best bet.

Posting here since its now buried in Discord

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

1 Like

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.

I use this command to upgrade my Prisma to 2.15
yarn add -W @prisma/sdk@2.15.0 @prisma/client@2.15.0 @prisma/cli@2.15.0

Then I encountered the following error while deploying to Netlify.

How may I overcome this error?:pray:

@andrew-hh

As noted:

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.

1 Like

Thanks to @danny for a downgrade to Prisma 12.11 path:

1 Like