Hey all ran into an issue I posted in github: <htt...
# sst
t
Hey all ran into an issue I posted in github: https://github.com/serverless-stack/serverless-stack/issues/93
f
@thdxr I'm taking a look at this now.
t
Thanks - I was curious to see how you thought about this issue
I don't have an obvious best way to fix it
f
Yeah let me talk to the team about it.
t
Feel like it supporting it would require a large change where instead of spawning a node process for every invocation, it gets spawned once per function and then messaged when there's an invocation - similar to how lambda in production works
f
hmm.. so in Prisma, does each Lambda opens one connection outside of the handler function, and holds onto that 1 connection until the end of the Lambda lifecycle?
t
It's not just one connection, it opens up a global connection pool. Every invocation of a lambda function will borrow a connection and return it once done
basically spins it up once during a cold boot and reuses it for every invocation (until aws decides to shut it down or spin up an additional container and the process repeats)
f
Oh... the global connection pool is managed by one Lambda?
And the other Lambdas borrow connections from it.
t
Not exactly let me draw up a contrived example:
Copy code
let count = 0

export const handler = function() {
  count++
  return {
    statusCode: 200,
    body: count.toString()
  }
}
In AWS, this won't always return 0
it'll return an unpredictable number based on how they spin up/down processes
in SST, this will always return 0
f
Let me know if it'd be easier to explain over a quick Zoom chat.
t
similarly, "count" is usually where we put the prisma connections. On cold boot it'll have to establish a connection to the database but on following invocations they get to reuse the connection.
f
Right, would it work if count is always 0 (ie. connection always needs to be re-established) on every invocation?
(Not ideal, but as a quick fix for now)
t
Yeah that's the workaround I'm doing now, manually disconnecting the connection at the end of every function. That works for local development but not ideal for production
f
Right
t
Larger point being global state definitely a bad thing in lambda functions but in a few cases like this it's valid to have it and would be cool if SST supported it
f
Agreed🙌 Adding that to the roadmap.
In the meanwhile, I think we would still need to put in the fix to respect the
ctx.callbackWaitsForEmptyEventLoop
flag for your setup to work?
Otherwise, you would need to change your Lambda code to manually kill the db connections right?
t
Yeah right now I have it manually killing in dev and not in prod. It's a fine work around but requires my to wrap all my handlers
I know in general people do rely on callbackWaitsForEmptyEventLoop so it'll probably come up as SST grows (as it deserves to 🙂 )
f
I just merged the fix to master. It's late here, we will cut a release tmr (Friday).
t
amazing! I'll give it a shot asap
works perfectly, good idea fixing in bootstrap.js thanks for the rapid turnaround!