Error due to sockets file getting deleted

Bug description

I use umami which uses prisma and I host the app on uberspace, a shared hosting provider.

The /tmp folder on my server gets deleted from time to time, which also deletes the `prisma-*.sock file and leads to this error:

2020-12-10 14:38:23,082 DEBG 'umami' stderr output:
PrismaClientKnownRequestError2: connect ENOENT /tmp/prisma-395d4bbf364fd00bc58da2d3.sock
    at PrismaClientFetcher.request (/home/simbo/umami/node_modules/@prisma/client/runtime/index.js:79355:15)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async getSession (/home/simbo/umami/.next/server/pages/api/auth/verify.js:198:19)
    at async /home/simbo/umami/.next/server/pages/api/auth/verify.js:258:15 {
  code: 'ENOENT',
  clientVersion: '2.12.1',
  meta: undefined
}

2020-12-10 14:38:30,493 DEBG 'umami' stderr output:
PrismaClientKnownRequestError2: connect ENOENT /tmp/prisma-395d4bbf364fd00bc58da2d3.sock
    at PrismaClientFetcher.request (/home/simbo/umami/node_modules/@prisma/client/runtime/index.js:79355:15)
    at processTicksAndRejections (internal/process/task_queues.js:93:5)
    at async module.exports.fJFN.__webpack_exports__.default (/home/simbo/umami/.next/server/pages/api/websites.js:1064:22)
    at async apiResolver (/home/simbo/umami/node_modules/next/dist/next-server/server/api-utils.js:8:1)
    at async Server.handleApiRequest (/home/simbo/umami/node_modules/next/dist/next-server/server/next-server.js:63:403)
    at async Object.fn (/home/simbo/umami/node_modules/next/dist/next-server/server/next-server.js:55:530)
    at async Router.execute (/home/simbo/umami/node_modules/next/dist/next-server/server/router.js:24:67)
    at async Server.run (/home/simbo/umami/node_modules/next/dist/next-server/server/next-server.js:65:1023)
    at async Server.handleRequest (/home/simbo/umami/node_modules/next/dist/next-server/server/next-server.js:33:450) {
  code: 'ENOENT',
  clientVersion: '2.12.1',
  meta: undefined
}

How to reproduce

1. use prisma client on linux
2. delete /tmp/prisma-*.sock file
3. see error

Expected behavior

Prisma should handle deleted temporary files (e.g. recreate).

Prisma information

prisma 2.12.1 (as dependency of umami 1.10.0)

Environment & setup

• OS: Red Hat 4.8.5-39
• Database: mysql
• Node.js version: 14.15.0
• Prisma version: 2.12.1

[timsuchanek]

I suggest introducing a parameter to the PrismaClient constructor like so:

new PrismaClient({
  engineMode: 'tcp'
})

or

new PrismaClient({
  engineMode: 'uds'
})

In the future, if we introduce N-API bindings for the engine, we can then also have:

new PrismaClient({
  engineMode: 'n-api'
})

[timsuchanek]

Thanks for the comments! @matthewmueller :

Any reason we chose /tmp? Was it because it’s writable in serverless environments? If that’s the reason, maybe we make that part configurable? You typically find socket files in /var/run or a place that isn’t cleaned up by the system by default.

In Lambda /tmp is the only writeable path, that’s the main reason.

Does /tmp get cleaned up while programs are running? I thought it just gets cleaned up on boot. Update: looks like it depends on the distribution and we won’t be able to rely on this behavior.

According to Lambda docs, it shouldn’t, but is possible depending on OS. (It’s something we can’t count on)

I think we could improve the abstraction with dependency injection

Interesting direction, but I would wait a bit until we understand the situation better before we introduce such a new concept

@yoshuawuyts :

If we ever make the switch to N-API, we would probably switch wholesale. N-API libraries will need to be compiled separately from the existing Rust binaries, which means we’d need to include both a library version of engine in order to allow people to switch at runtime. This seems undesirable.

That is correct! I was just thinking about other possible values for such an enum, but it’s indeed unlikely that it would end up in there. Allowing both at the same time still sound desirable to me though, but that could e.g. be configured in the schema instead.

In a related issue, https://github.com/prisma/prisma/issues/4557 we got reports, that disabling UDS and enabling TCP again fixed their issue. That’s why we just changed the default back to TCP until we understand the UDS situation better.

Therefore this issue can be closed.