If you want to think of it as a bug feel

If you want to think of it as a bug feel free. But just keep in mind that theres 0 expectation of close events of any form running. It will generally run for the most part but not always

Detuks•8/4/25, 7:17 PM

Is there any documentation around it?

Larry•8/4/25, 7:22 PM

Think about it. What if a meteor hit the location where the DO was running. Sure, it's designed so you don't lose any data that's aknowledged as written to storage, but any DO instances running in that data center will instantly disappear from memory. The next request will instantiate it somewhere else, but how could close code run on the instance that was running on hardware that is now molten metal? In reality, there are a large number of reasons why it could go down, a re-deploy is perhaps the most common. Maybe Cloudflare could add a feature for that particular situation, but since you have to take intermittent network failures into account anyway, I doubt they will.

tl;dr; design so your system works if the DO disappears instantly.

Detuks•8/4/25, 7:25 PM

Ye didn't think about it this way

Detuks•8/4/25, 7:27 PM

makes my whole billing system 5x harder ehh

Detuks•8/4/25, 7:27 PM

but so on DO update they just poof out of existence and every client gets dced?

Larry•8/4/25, 7:28 PM

My original thought was to have you count them upon alarm or if you design the dashboard to reach out during that call. I forget why that was rejected, but state.getWebsockets.lengthstate.getWebsockets.length will get your the current active count.

DDetuks but so on DO update they just poof out of existence and every client gets dced?

Larry•8/4/25, 7:37 PM

I don't know if clients are disconnected on every redeploy. I'm told that hibernated WS are maintained on the machine of the Worker that originally proxied the WS upgrade request. That worker is usually (always?) updated in the same update deploy but in theory the machine and its hibernated WS connections might be preserved. You'd have to devise an experiment to confirm. However, I'd advise against relying upon whatever you learn. It's an implementation detail that Cloudflare doesn't want you to design to.

One thing you can be certain of though is that when you call state.getWebsockets.lengthstate.getWebsockets.length you'll get a reasonable count for that instance. I still don't recall why you don't want to use that?

Larry•8/4/25, 7:37 PM

actually it's state.getWebSockets().lengthstate.getWebSockets().length

Detuks•8/4/25, 7:38 PM

Im more worried now about my billing implementation

Detuks•8/4/25, 7:38 PM

I use alarm to bill users there

Detuks•8/4/25, 7:38 PM

plus can bill last time on socket close

Detuks•8/4/25, 7:39 PM

I guess missing last websocket close is not end of the world tho

Larry•8/4/25, 7:39 PM

Can you bill on socket opens?

Detuks•8/4/25, 7:39 PM

I start timer on socket opens

Detuks•8/4/25, 7:40 PM

and every X minutes I bill client

Larry•8/4/25, 7:40 PM

Like a

setTimeout()

setTimeout()

Detuks•8/4/25, 7:40 PM

I set alarm

Detuks•8/4/25, 7:40 PM

so it would sleep

Detuks•8/4/25, 7:40 PM

*hibernate

Larry•8/4/25, 7:43 PM

I have a feeling you might be overcomplicating this. How many clients per DO instance do you expect?

LLarry I have a feeling you might be overcomplicating this. How many clients per DO ins...

Detuks•8/4/25, 7:44 PM

Maybe I am. I expect mostly 1 but could get to 10

Larry•8/4/25, 7:45 PM

Can you simply cycle through the list of connections at each alarm point and then write to storage some record of which were active for that tick of the alarm?

Larry•8/4/25, 7:45 PM

Then periodically (once a day, once a week, once an hour), you could fetch that data out of storage?

LLarry Can you simply cycle through the list of connections at each alarm point and the...

Detuks•8/4/25, 7:46 PM

That is what I do. I make a billing record or how much time was used + info and how much it cost

Detuks•8/4/25, 7:46 PM

but I also subtract credits

Larry•8/4/25, 7:46 PM

Then why do you care about missing open and close events?

Detuks•8/4/25, 7:47 PM

but if I bill every 10x minutes and user closes ticket after 8 minutes I still want to bill for those 8 minutes

Larry•8/4/25, 7:47 PM

So, run your alarm once a minute

Detuks•8/4/25, 7:47 PM

ye but then I would pay for DO more

Detuks•8/4/25, 7:48 PM

Here it comes down to how often will I miss socket close events

Larry•8/4/25, 7:48 PM

Now I understand. But the alarm will run really fast. It's like a few ms per alarm.

Detuks•8/4/25, 7:50 PM

but DO goes to sleep only after 10 seconds

Detuks•8/4/25, 7:50 PM

plus I would spam my database with many records

Detuks•8/4/25, 7:51 PM

so I think 15 minutes might be my sweetspot

Larry•8/4/25, 7:51 PM

True but you only pay for the time where it's running your own code + if there are any open fetches. Running an alarm will only incure a few ms unless the alarm makes a fetch

Larry•8/4/25, 7:52 PM

Don't spam your database with a new row on every alarm run where it's open. Keep a record per account and update it.

LLarry Don't spam your database with a new row on every alarm run where it's open. Keep...

Detuks•8/4/25, 7:52 PM

Where would I keep that record?

Larry•8/4/25, 7:53 PM

In the DO storage

Detuks•8/4/25, 7:53 PM

DO sql storage?

Larry•8/4/25, 7:53 PM

If you want to pull it out to an external database, do that in batches.

Larry•8/4/25, 7:54 PM

Yes, DO SQL storage or even DO KV storage.

Detuks•8/4/25, 7:54 PM

But they add cost as well

Larry•8/4/25, 7:54 PM

The API for DO KV storage is super simple and avoids SQL complexity. Your only decision is how to name your keys.

DDetuks But they add cost as well

Larry•8/4/25, 7:56 PM

My advice is to get your system up and running and worry about costs after you receive a surprising bill

Larry•8/4/25, 7:57 PM

You could model storage costs + reads + writes. You don't really need to model the clock time for alarm running though. It'll be negligible even with 1 minute granularity

Detuks•8/4/25, 7:58 PM

I guess will get it out and see how it performs. Can later easily change frequency of alarms

Detuks•8/4/25, 7:59 PM

But ye thanks for explanation!

DDetuks and every X minutes I bill client

UnsmartOP•8/5/25, 1:00 AM

I think the graphql api exposes some analytics around websocket stuff for DOs but why bill on a metric in which you are not billed on?

UUnsmart I think the graphql api exposes some analytics around websocket stuff for DOs bu...

Detuks•8/5/25, 4:47 AM

My own billing. I provide other features

If you want to think of it as a bug feel

Similar Threads

Similar Threads

Similar Threads