like for example, if a websocket connection lasts 10 minutes (no disconnects etc), is that a single

like for example, if a websocket connection lasts 10 minutes (no disconnects etc), is that a single 10 minute “request”?

AAvi like for example, if a websocket connection lasts 10 minutes (no disconnects etc...

Hello, I’m Allie!•6/8/24, 10:09 AM

Yes, plus 10 minutes Wall Time, which is the downside(if you aren't constantly receiving packets anyway)

HHello, I’m Allie!Yes, plus 10 minutes Wall Time, which is the downside(if you aren't constantly r...

AviOP•6/8/24, 10:19 AM

i see - what about sending packets? it’s a very chatty app, there’s almost always about one message per second being broadcast to all connected clients

AviOP•6/8/24, 10:20 AM

i guess the thinking is that each of those messages might take only a fraction of a second to handle, so might as well have the app take “micro naps”

AAvi i guess the thinking is that each of those messages might take only a fraction o...

Hello, I’m Allie!•6/8/24, 10:22 AM

If it is constantly sending messages, it probably won't ever actually hibernate, but iirc since it is eligible to be evicted, you wouldn't be billed for the time in between

HHello, I’m Allie!If it is constantly sending messages, it probably won't ever actually hibernate,...

AviOP•6/8/24, 10:25 AM

oh fascinating, so you aren’t charged even if it doesn’t actually hibernate?

AviOP•6/8/24, 10:26 AM

like it’s only billing time when you CANT hibernate?

AAvi like it’s only billing time when you CANT hibernate?

Hello, I’m Allie!•6/8/24, 10:27 AM

That's how I understand it. If you are doing work, processing an event, and haven't yet returned, it will bill you. If you have returned, then even if you haven't been evicted yet, you won't be billed.

Hello, I’m Allie!•6/8/24, 10:27 AM

Might be good to double check tho

AviOP•6/8/24, 10:29 AM

that’s good to keep in mind for a possible cost optimization

AviOP•6/8/24, 10:30 AM

now my challenge is figuring out how to handle managing the lifecycle of a postgres connection through a websocket request… i guess the AsyncLocslStorage API is the move here

AviOP•6/8/24, 10:31 AM

just hard to wrap my brain around how e.g. errors are handled, since unlike a simple http request/response flow, the websocket flow is much more complicated

AviOP•6/8/24, 10:31 AM

what if it errors out? what if the connection disconnects?

AviOP•6/8/24, 10:31 AM

it’s not like there’s a top level “wait for websocket to finish” promise

AAvi now my challenge is figuring out how to handle managing the lifecycle of a postg...

Hello, I’m Allie!•6/8/24, 10:33 AM

This is still within the DO?

HHello, I’m Allie!This is still within the DO?

AviOP•6/8/24, 10:33 AM

yes

AAvi yes

Hello, I’m Allie!•6/8/24, 10:33 AM

Why not just store it in the in-memory state directly?

AviOP•6/8/24, 10:33 AM

“it” as in the database client object?

AAvi “it” as in the database client object?

Hello, I’m Allie!•6/8/24, 10:34 AM

Yeah

HHello, I’m Allie!Yeah

AviOP•6/8/24, 10:34 AM

apparently it must be created and destroyed with every request context

AviOP•6/8/24, 10:35 AM

In serverless environments such as Vercel Edge Functions or Cloudflare Workers, WebSocket connections can't outlive a single request. That means Pool or Client objects must be connected, used and closed within a single request handler. Don't create them outside a request handler; don't create them in one handler and try to reuse them in another; and to avoid exhausting available connections, don't forget to close them