https://www.prisma.io/ logo
Join Slack
Powered by
Hey, we’re moving some of our stack to use AWS Lam...
# orm-help
a
Hey, we’re moving some of our stack to use AWS Lambda’s and are sometimes seeing this error 
Timed out fetching a new connection from the connection pool
. I have a couple of q’s around this: • Is this error only thrown when prisma client tries to get a connection from the pool to run a query? Or is also thrown when the DB has reached it’s max connection limit and the prisma client isn’t able to reserve connections to create a connection pool? • If it’s only thrown in the first case, what could be the possible reasons for it to be thrown when all queries are executed sequentially and connection pool size is 5? • We get a prisma client by doing ->
Copy code
const getClient = async () => {
// get connection string stored in AWS parameter store
  return new PrismaClient()
}
And then we call 
getClient
in our handler. So basically anytime a handler is called a new prisma client is initialised. What does this mean in terms of the connection pool? Will prisma create a new pool every time we do 
new PrismaClient()
?
r
@Ahmar Suhail 👋 • Yes this error is thrown when Prisma cannot fetch any more connections from the database. • Is this function called every time? If so I would strongly suggest creating 
PrismaClient
outside the handler as each 
PrismaClient
instance creates a new connection pool.
So ideally your 
PrismaClient
instance should look something like this: https://github.com/ryands17/graphql-api-cdk-serverless-postgres/blob/main/lambda-fns/db.ts
a
amazing! thanks so much
💯 1
j
Sorry, I think @Ryan got it wrong here.
Let me reread your question in detail.
Timed out fetching a new connection from the connection pool
is indeed only when the connection pool does not return a connection to the Client in the defined amount of time. The database is not involved here at all. This is usually the case because the connection pool has a pool size limit (defined via 
connection_limit
). When all those are in use for running queries, additional queries have to wait - and after x seconds you get the error message you posted above.
The error can also be triggered when connection creation takes to long when getting a new connection from the connection pool. But usually another error 
connect_timeout
is triggered first (which is half the amount of seconds than 
pool_timeout
).
That being said, we are left with this question:
What could be the possible reasons for it to be thrown when all queries are executed sequentially and connection pool size is 5?
And that is a really good question. Are you sure everything is sequential? Activating all logging for queries could be a good way to find out what is running in parallel.
You could also up the 
pool_timeout
to a really high number and see what happens.
Are you seeing any other errors on that Lambda before?
a
Hey @janpio 👋🏼 just to clarify, if the issue was that the DB reached the max connection limit, I would probably see a 
connect_timeout
first?
And yup, I'm sure everything is sequential. It's actually a really simple function:
Copy code
handler = () => {

  const prisma = await getDatabaseConnection();

  const {
    Records: [{ messageAttributes: data }],
  } = event;

  const { lead } = getPartsFromWebhookData(data);

  console.log("Converting lead: ", lead);

  const eventRequest = await prisma.event_requests.findUnique({
    where: { id: lead.cf_request_id },
  });

 // Do stuff here 
}
error was being thrown at that findUnique. Complete error log:
Copy code
{
  "errorType": "Error",
  "errorMessage": "\nInvalid `prisma.event_requests.findUnique()` invocation:\n\n\n  Timed out fetching a new connection from the connection pool. (More info: <http://pris.ly/d/connection-pool>, Current connection limit: 5)",
  "clientVersion": "2.24.1",
  "stack": [
    "Error: ",
    "Invalid `prisma.event_requests.findUnique()` invocation:",
    "",
    "",
    "  Timed out fetching a new connection from the connection pool. (More info: <http://pris.ly/d/connection-pool>, Current connection limit: 5)",
    "    at cb (/opt/nodejs/node_modules/@prisma/client/runtime/index.js:35229:17)",
    "    at process._tickCallback (internal/process/next_tick.js:68:7)"
  ]
}
j
If you the connection limit was hit, you should see that direct error from the database even sooner - it usually returns instantly. Even if not, the 
connect_timeout
should trigger and give you taht error message.
Ok, that indeed does not make much sense then.
As you are starting the database for each request (inside the handler), are you also closing it each time with 
prisma.$disconnect()
at the end?
Optimally add 
pool_timeout=300
to your connection string and see if it indeed waits that long, and then outputs the pool timeout error message happens again or something else.
That would be a good way to uncover other potentially hidden errors.
a
nope, we're not doing any 
prisma.$disconnect()
. I'll also be updating the code to https://github.com/ryands17/graphql-api-cdk-serverless-postgres/blob/main/lambda-fns/db.ts as ryan suggested
ah okay, sounds good
6 Views
Open in Slack
PreviousNext
Powered by