Not for the init() + actual call if they are pipelined. But you can even use the same RpcTarget acro

Not for the init() + actual call if they are pipelined.
But you can even use the same RpcTarget across requests, and followup RPCs would go straight to the target host/DO instead of the usual routing. If this matters to your app is a whole other story

Llambrospetrou Not for the init() + actual call if they are pipelined. But you can even use the...

Larry•10/22/25, 12:01 PM

But, if I understand this correctly, the problem with using the same RpcTarget across requests is that you now have a resource on the server you have to worry about being left dangling, right?

LLarry But, if I understand this correctly, the problem with using the same RpcTarget a...

lambrospetrouOP•10/22/25, 12:03 PM

Well, at some point it's going to be teared down since the client worker will be evicted, but yes. If you are not careful it could end up consuming resources and resetting your DO eventually, if clients holding the RpcTarget don't terminate ever.

Ccloudkite Nice pattern to handle this is to have init return a RPCTarget with methods you ...

Yoh•10/22/25, 3:47 PM

We can't make fetch private though, so there would still be a way to bypass the init call for websocket upgrade requests, right? So there's at least one place we need to remember to call init or add the header, whichever method we use to pass in the entity id?

YYoh We can't make fetch private though, so there would still be a way to bypass the ...

cloudkite•10/22/25, 7:42 PM

Yup using a custom header for websockets upgrade request which I then store using serializeAttachment. This way don’t have to store on a variable on the DO and it can also store other context about the web socket connection

cloudkite•10/22/25, 7:48 PM

We have found it’s easier to reason about if DO instance variables are only things that can be set in constructor. Otherwise it’s easy to accidentally use a instance variable which hasn’t been set like entity ID

Ccloudkite Yup using a custom header for websockets upgrade request which I then store usin...

Larry•10/22/25, 8:00 PM

Why serializeAttachment rather than storage? Isn't the information @Yoh is talking about for the entire DO instance not just one WebSocket connection?

LLarry Why serializeAttachment rather than storage? Isn't the information @Yoh is talki...

cloudkite•10/22/25, 8:25 PM

Just found it convenient as in our case we also use the same header to pass info that’s specific to single connection

cloudkite•10/22/25, 8:27 PM

Tying it to a websocket also removes ability to use it from non-websocket context which feels cleaner

Yoh•10/22/25, 10:29 PM

I think in my case I'll keep it in DO storage, not an individual ws client connected to the DO. I might still want to know the original entity id even when I have no connected clients.

1984 Ford Laser•10/23/25, 4:44 AM

So I'm finally making the jump to SQLite in DOs and don't have any prior experience with SQL, are there any gotchas I need to be aware of when using things like VIEWs or TRIGGERs? The pipelines I'd be looking at would be at most hundreds of rows total in a table, using index columns where possible. Generated columns from JSON data also sounds interesting for some uses. My use cases would usually be write once-read a few times at most, wanna simplify how I'm storing and managing my relational data

1984 Ford Laser•10/23/25, 5:09 AM

Interesting I'll take a look. I don't want to add a bunch of extra complexity to my projects by havin to work with an ORM but if it isnt intrusive them Im down. Is it a heavy dependency?

James•10/23/25, 1:34 PM

drizzle has annoying bugs, I find it easier to stick to SQL at runtime

João Castro•10/23/25, 1:39 PM

Yup, and their types are wrong in some scenarios which can cause you headaches to debug in the future. I still find it to be good if you avoid the relational api, which is where most bugs appear

BBrayden Yes, reached out. They mentioned they'd get this merged in tomorrow or Monday.

João Castro•10/23/25, 1:41 PM

Btw, they still didn't merge this and return values for transactions remain broken with the DO driver

JJoão Castro Btw, they still didn't merge this and return values for transactions remain brok...

Brayden•10/23/25, 1:53 PM

Just pinged again

JJoão Castro Btw, they still didn't merge this and return values for transactions remain brok...

Brayden•10/23/25, 2:01 PM

Tests are running and merging for that PR right now

Ggnomesgames Yeah that's true, their type let you do invalid things. I do very basic CRUD so ...

James•10/23/25, 3:21 PM

I found good results using drizzle kit to define schema and migrations, but for runtime, I have a simple custom handler for casting types on return from the DO using the existing schema definitions in TS.

The only aspect one needs to be careful with raw SQL and this approach is consistent type casting on writes for fields like dates as numbers or string however you choose to store them.

James•10/23/25, 3:23 PM

The side perk to custom SQL is it's much much easier for an LLM to debug/refine code based on the SQL. It's a level of indirection with ORMs sometimes.

JJames The side perk to custom SQL is it's much much easier for an LLM to debug/refine ...

Larry•10/23/25, 4:34 PM

I find myself more and more optimizing my software design decisions based upon the cognizability of it to an LLM. A funny thing about my own code and LLM use is that if I have poorly named identifiers it can throw it into a doom loop. I called something "serialize" and there was JSON in the area and it constantly thought the output was a string, but it was really pre-processing before turning it into a string. Once I renamed it, the LLM had no trouble.

Aries•10/23/25, 4:38 PM

Is the lifetime of a DO predicable? How long until it kills itself?

Aries•10/23/25, 4:39 PM

I have a semi-short lived use case, for stateful requests, and don't feel like they need to store to a persistant store, but I'm worried they'll be prematurely killed.

Aries•10/23/25, 4:40 PM

Is it after 5s in-memory is wiped, or longer?

Aries•10/23/25, 4:40 PM

Can't find resources on this.

AAries Is the lifetime of a DO predicable? How long until it kills itself?

Larry•10/23/25, 4:49 PM

It's a bit complicated, but look here: https://developers.cloudflare.com/durable-objects/concepts/durable-object-lifecycle/

Cloudflare Docs

Lifecycle of a Durable Object

This section describes the lifecycle of a Durable Object.

Larry•10/23/25, 4:50 PM

Focus on the diagram. It has the timing of eviction and hibernation.

LLarry It's a bit complicated, but look here: https://developers.cloudflare.com/durable...

Aries•10/23/25, 5:37 PM

So, according to this, if I queued no-operation , I could prolong past the 10s?

AAries So, according to this, if I queued no-operation ``setTimeout``, I could prolong ...

Larry•10/23/25, 5:40 PM

Yes. That's one way people keep DOs alive. I think some people also use alarms. Not sure which is best.

TrueBrain•10/23/25, 6:06 PM

Is there a way to execute a worker from a DO where the walltime of this worker is not added to the walltime of the DO?

It might be a bit cheeky, but what I am trying to do:

Have a DO take care of administration for my users.
Once in a while (via alarms), the DO asks a worker to check in with an external API for an update.
This external API can be extremely slow. Think 10+ seconds to come up with an answer. As such, the worker returns a response near-instantly, while via the external API fetch is finished, and a D1 table is updated.
This way the DO isn't blocked on the fetch for very long.

From a cost perspective, paying for 10s of walltime is ofc very expensive (especially as it is just waiting). So the idea of this setup was that the DO would run in short burst, and let the worker do the waiting on the external API.

However, and documentation suggests the same: Cloudflare is being nice (which I appreciate btw) and doesn't charge for the second worker invocation. But also adds the walltime of the second worker to the DO walltime. And I can't find a way for it to stop doing that

I tried several things:

Use service-bindings (works, but walltime is added together)
Use service-bindings and set smart placement on the worker (works, but DO now shows both requests in the GB-s graph, suggesting they are both billed under DO pricing)
Use direct HTTP (doesn't work, as you can't call a worker on your own account from another worker without a service-binding, it seems)

Any advise or best practice how to deal with DOs and fetches to external APIs that are very slow?

TTrueBrain Is there a way to execute a worker from a DO where the walltime of this worker i...

Hard@Work•10/23/25, 6:23 PM

DO invokes Worker via Service Binding, Service Binding returns after initiating work with , allowing Durable Object to be evicted. Worker continues processing, and then once complete, uses the calling DOs ID to create a stub to it, and returns the response.

HHard@Work DO invokes Worker via Service Binding, Service Binding returns after initiating ...

TrueBrain•10/23/25, 6:24 PM

That is what I tried. But the walltime of the second worker is added to the DO, the dashboards tell me

TrueBrain•10/23/25, 6:26 PM

Basically I am trying to bypass https://developers.cloudflare.com/workers/platform/pricing/#service-bindings

But my experiements show for a DO it should read "walltime", not "CPU time"

TTrueBrain That is what I tried. But the walltime of the second worker is added to the DO, ...

Hard@Work•10/23/25, 6:26 PM

To confirm, the Worker immediately returns to the DO, right?

TrueBrain•10/23/25, 6:26 PM

Yes

Hard@Work•10/23/25, 6:26 PM

It doesn't do any work first?

TrueBrain•10/23/25, 6:27 PM

The DO object itself is also evicted in a few ms

TrueBrain•10/23/25, 6:28 PM

So from whatI can tell, everything is working exactly how you (and I) expect ... except for where the bill lands

TTrueBrain So from whatI can tell, everything is working exactly how you (and I) expect ......

Hard@Work•10/23/25, 6:29 PM

Just to confirm, does your bill reflect that, or is this only in the dashboard?

TrueBrain•10/23/25, 6:30 PM

Dashboard. The "Request Wall Time" of the DO, to be more exact.

TrueBrain•10/23/25, 6:31 PM

or "Billable Duration" for that matter

TrueBrain•10/23/25, 6:35 PM

No, I am wrong. The "Requests" and "Request Wall Time" combine both the DO and Worker. But "Billable Duration" appears to only account for DO walltime.
But the second workers dashboard only shows zeros, not even CPU time.

Now I am just confused

LLarry I find myself more and more optimizing my software design decisions based upon t...

gruntlord6•10/24/25, 12:56 AM

Had that with a value called redis , was painful to watch

Burrito•10/24/25, 2:27 AM

I've tried ORM, query builder, and raw SQL in various backend projects. They all have their issues, but nowadays I'm leaning more towards raw SQL end of the spectrum.

gruntlord6•10/24/25, 3:30 AM

Yea I started with an orm because a starter I was using had it pre configured but it was way more trouble then it was worth, especially because AI is very good at writing sql when you give it a spec

flof.fly•10/24/25, 12:54 PM

Hi I'm looking to use Cloudflare DO x Websockets, can anyone share their experience on reliability and scalability of it?

Fflof.fly Hi I'm looking to use Cloudflare DO x Websockets, can anyone share their experie...

Larry•10/24/25, 1:08 PM

The key is to assume the connection will break often and design for reconnection and resumability. If the server never needs to initiate communication, I use a lazy [re-]connection strategy where the next time the client needs to send something, it first checks if the connection is up and if not re-connects. For situations like chat where you need the server to reach out to the client, you will have to use the hooks for sensing when the connection is broken and reconect. There is a package that Cloudflare Agents use for this purpose. I have forked that for my own purposes but you could just use that.

SH•10/24/25, 6:45 PM

Is there a way to register an unhandledrejection event handler in Durable Objects?