prisma: Error in connector: Error creating a database connection. (Operation timed out (mobc timeout))
Bug description
Sometimes, due to DB connections limit, the client fails with this error:
Error in connector: Error creating a database connection. (Operation timed out (mobc timeout))
at PrismaClientFetcher.request (/home/nicosampler/develop/loan-system/node_modules/@prisma/client/runtime/index.js:78786:15)
at runMicrotasks (<anonymous>)
at processTicksAndRejections (internal/process/task_queues.js:93:5)
at async eval (webpack-internal:///./graphql/migration/resolver.ts:139:17)
(node:106069) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). To terminate the node process on unhandled promise rejection, use the CLI flag `--unhandled-rejections=strict` (see https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode). (rejection id: 75)
my DB configuration is like so: DATABASE_URL="mysql://someUser:somePass@host/db?connection_limit=10"
Note: connection_limit
How to reproduce
It happened to me when trying to create/update/delete several entities at the same time, for example:
const res = [largeArray]
res.forEach(async (client) => {
const createdClient = await context.prisma.client.create({data: {client}})
})
Expected behavior
The client should be able to recover from a timeout connection.
Environment & setup
- OS: Ubuntu
- Database: Mysql
- Node.js version: 14
- Prisma version: 2.11.0
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Reactions: 8
- Comments: 44 (16 by maintainers)
I can reproduce this with a heroku database with connection limit of 10 and this simple script.
All timed out calls doesn’t recover. Connections in the heroku reaches max of 11 then it starts to give timeouts.
Reproduction: https://github.com/harshit-test-org/prisma-issue-4280
I am using the latest version of prisma (2.15.0). It’s throwing the new error (https://github.com/prisma/prisma-engines/pull/1515). But the error message doesn’t make sense. I have 150 connections as limit, 10 connections are used but it still fires an error:
The connection limit of my DB (postgres) is 180
Same issue here.
BTW I’m using Blitz.js + Vercel + DigitalOcean. More info about this stack at https://blitzjs.com/docs/deploy-vercel.
@mjknight50 so it looks like you have a current connection limit of 3, you can comfortably have 3 concurrent prisma queries sent at once.
Or if you’re running the Prisma Client inside a node http server, each handler runs concurrently, you can have 3 simultaneous visitors each sending 1 query.
If you’re above this, these requests will get queued and processed in FIFO order. If the requests spend too long in the queue, they will start to timeout.
This is the problem you’re running into and the solution is to either reducing the number of requests or increase the connection_limit parameter.
Just a note that increasing the connection_limit has tradeoffs and you may want to upgrade your DB to handle more connections. This answer may help if you’re running on RDS.
We found a limitation in the current version that even with
pool_timeout=0
(which should disable the timeout) runs into a timeout at ~30 seconds after you start. Does this match your observations when you see the error?I am also using the latest version of
@prisma/client
and@prisma/cli
of2.15.0
and am seeing that I’m getting the same error above, except it mentions that there are 0 connections in use.I am deploying to Firebase cloud functions, running on Node 12.
This is how I instantiate my PrismaClient
Thanks, everyone for your comments! We are looking into it right now and discuss solutions internally. We will definitely make sure to give you a solution for this.
@pantharshit00 I can reproduce that also for the
Can't reach database server
error, when the docker DB container is not started.I found it as a regression because some time ago (a few weeks or months ago) it worked like a charm - I could start the db when the server was running and it could reconnect itself when e.g. the
findMany
was called (implicit connect).@janpio thank you for your response!
I’m migrating data from an old environment to a new one. To improve speed, I spin up some child process (16) which runs some queries. All the child processes are using the same Prisma instance. However, it also occurs if I use a new PrismaClient per child process.
So I think the reason that Prisma triggers this is because of a lot of queries running in parallel as you mentioned.
Adding the
&pool_timeout=0
doesn’t seem to fix the issue 😦 . You mean to add it like this :...m:5432/postgres?pool_timeout=0
, right?I am having the same issue.
@timsuchanek I have tried previously that with the same result. When I’m running a big amount of operations sooner than later I ended with the same error.
Even, In the ticket description, I’m running it with 10.
I think this problem is with the query engine https://www.prisma.io/docs/concepts/components/prisma-client/query-engine#the-query-engine-at-runtime we are facing a lot of stability problems with the query engine: timeouts, OOM…
This error shows with or without pgBouncer or cloudsql-proxy.
We face this also at my work and we are using pgBouncer. What would be really useful is a stacktrace when possible because it’s very hard to find out where is the problem.
Im having the same issue
UPDATE: I had to serialize my requests being made to the database in order to workaround this issue. Although not sure why prisma doesn’t handle this
The library i used was throat js which allows you to add a concurrency on an array of factory functions that returns promises and runs them in sequence