Cloudflare Developers•2mo ago

Now while Ive been loooking at this DO site the Perth option has disappeared from Melbourne entirely

hopefully someone has seen me complaining and is fixing this as we speak

1984 Ford LaserOP•10/21/25, 1:40 AM

hahahaha yes someone is listening, 20252025 is now appearing in Sydney

PhoenixSpace•10/21/25, 1:41 AM

11984 Ford Laser Now while Ive been loooking at this DO site the Perth option has disappeared fro...

lambrospetrou•10/21/25, 7:23 AM

Doubt it

But, yes, your observation and what others said above is mostly true that a DO will be created in the initially created colo if possible. There are cases it will move out of that, like when that colo has network issues and is taken out of the network for a while and the DOs hosted there will move elsewhere in the same region.

In the long-term future, our hope is for DOs to be moving more often closer to requests, but not yet.

Llambrospetrou Doubt it 😅 But, yes, your observation and what others said above is mostly tr...

1984 Ford LaserOP•10/21/25, 7:36 AM

And if a DOs storage is deleted using deleteAll()deleteAll(), and then the same instance is requested with same id, it will respawn in the same colo right?

11984 Ford Laser And if a DOs storage is deleted using `deleteAll()`, and then the same instance ...

lambrospetrou•10/21/25, 7:37 AM

At the moment, yes, we have a record of all created DOs even without storage. As I said, though, I wouldn't depend on this because we want to change it in the future. Just explaining why you are seeing the stickiness.

Llambrospetrou At the moment, yes, we have a record of all created DOs even without storage. As...

1984 Ford LaserOP•10/21/25, 7:39 AM

Yeah that's cool I knew something was in the pipeline, if it is ready by end of Q1 26 then I'm good

11984 Ford Laser Yeah that's cool I knew something was in the pipeline, if it is ready by end of ...

lambrospetrou•10/21/25, 7:40 AM

FYI, I didn't specify any timelines.

1984 Ford LaserOP•10/21/25, 7:40 AM

Ahh so I should expect :soontm:

1984 Ford LaserOP•10/21/25, 8:28 AM

Anyone used DOs to ingest/process WebRTC streams over WebSockets? I wanna export a frame of a stream every X frames and send it off to be processed elsewhere. I know about Realtime and stuff but there're other processes that would interact with this and benefit from it being on DOs

Ggnomesgames This is still happening 🥺, anything deployed on the DO side that might explain ...

1984 Ford LaserOP•10/21/25, 9:11 PM

No changes in code in the last few days?

Ggnomesgames This is still happening 🥺, anything deployed on the DO side that might explain ...

niall•10/21/25, 9:48 PM

also seeing a whole bunch of these since the 18th

Mmvgrim Also, seems like the Data Studio doesn't expose KV store data that is backed by ...

Yoh•10/21/25, 10:01 PM

I'm using the KV api for a sqlite backed durable object, and these records don't show up in the data studio. Have we heard if this is something that will be added later?

YYoh I'm using the KV api for a sqlite backed durable object, and these records don't...

mvgrim•10/21/25, 10:05 PM

This was mentioned by the devs as something they plan to support, at minimum read-only. So our voices do help show there's a desire for the functionality.

Need_Not•10/21/25, 10:16 PM

my do is in ./worker/durable-objects/user-do.ts
would i put that as the script_name?

NNeed_Not my do is in ./worker/durable-objects/user-do.ts would i put that as the script_n...

1984 Ford LaserOP•10/21/25, 10:16 PM

Whatever is the

name

name

in your wrangler

NNeed_Not my do is in ./worker/durable-objects/user-do.ts would i put that as the script_n...

Hard@Work•10/21/25, 10:17 PM

Assuming it is the same Worker, you don't need a script name at all

11984 Ford Laser Whatever is the `name` in your wrangler

Need_Not•10/21/25, 10:18 PM

The class name is UserObject but how does it know where that is? Does it scan every class in every file? Also how do i make it have autocomplete when using the DO. How does typescript know what type of DO i'm working with when i get it?

NNeed_Not The class name is UserObject but how does it know where that is? Does it scan ev...

Hard@Work•10/21/25, 10:18 PM

It needs to be exported from the entrypoint of the Worker

HHard@Work It needs to be exported from the entrypoint of the Worker

Need_Not•10/21/25, 10:19 PM

oh. Also for typescript i realized the binding is per class

Yoh•10/21/25, 10:23 PM

I think it's pretty typical that we have a durable object represent some entity like a user or a session, so we use idFromName, and then have that DO handle things for that entity.

Once I'm in the DO, however, it doesn't know the original entity id. I'm awkwardly passing in the entity id via a public init method, and then storing it in DO storage, so that when it wakes up after eviction (from a websocket message arriving or an alarm), it can "remember" its own entity id.

Are there other workarounds people are using that I'm not considering? Is there a less clunky way of the DO being aware of its own entity id? Thanks!

YYoh I think it's pretty typical that we have a durable object represent some entity ...

Hard@Work•10/21/25, 10:24 PM

That's generally the best you can do at the moment. If you know when a DO is created, then you could ensure you only push in the name of the DO on creation, but otherwise, it should be passed every time to ensure it has it in the event it is new

HHard@Work That's generally the best you can do at the moment. If you know when a DO is cre...

Yoh•10/21/25, 10:27 PM

Got it, thank you. I'll keep doing this for now then!

YYoh I think it's pretty typical that we have a durable object represent some entity ...

Larry•10/21/25, 10:54 PM

I do it in a header for both HTTP and the WebSocket upgrade requests. You can't set the header for WebSockets in the browser but you can add it in the Worker fetch handler when it processes the WebSocket upgrade request. This is my utility for handling both HTTP and WebSocket DO requests: routeDORequestrouteDORequest. If you use it, the DO will automatically get the headers on each request or WebSocket upgrade. You'll still have to pluck them out of the headers and stick them in storage. If you want to see how I do it, look at the source code here.

LLarry I do it in a header for both HTTP and the WebSocket upgrade requests. You can't ...

Yoh•10/21/25, 11:10 PM

This is neat, thanks. I imagine this works really well if requests are always routed directly into the DO. (I've got a few other places accessing the DO, such a scheduled handler, so perhaps for me the init method is more ergonomic because it works there too)

Jacob Marshall•10/21/25, 11:36 PM

Does anybody know whether a Durable Object is moved back to it's original colo after it's been "moved" to a different colo during an outage (for example)? This is in reference to what Josh Howard said in this video with Aaron Francis. I would assume it does move back to it's original colo - but it's one of those things that are annoying to test haha, so I don't know the definitive answer.

YouTube

✂️ "We can move Durable Objects"

23 seconds · Clipped by Jacob Marshall · Original video "How Durable Objects and D1 Work: A Deep Dive with Cloudflare’s Josh Howard" by Aaron Francis

Need_Not•10/22/25, 12:04 AM

Is there a limit how far in the future an alarm is set? I want to schedule for 30d in the future if that works.

NNeed_Not Is there a limit how far in the future an alarm is set? I want to schedule for 3...

Jacob Marshall•10/22/25, 12:19 AM

Assuming it's still accurate, this should answer your question: https://community.cloudflare.com/t/durable-objects-alarm-limit/512367

YYoh This is neat, thanks. I imagine this works really well if requests are always r...

Larry•10/22/25, 1:39 AM

What do you mean by "scheduled handler"?

LLarry What do you mean by "scheduled handler"?

Yoh•10/22/25, 1:48 AM

I have a cron job (the scheduled export in the worker entrypoint) which interacts with some DOs. So in this handler, I get DO stubs using idFromName, call the init function so they know their own entity id, and then call whatever other DO methods I need. In this case it wouldn’t be as nice to reimagine this as a fetch call where I inject my own headers

YYoh I have a cron job (the scheduled export in the worker entrypoint) which interact...

Larry•10/22/25, 2:09 AM

Makes sense. Using Workers RPC is more efficient. If it's possible that the first access to a DO instance comes from this cron job RPC call, then your init call is the only way I can think to handle it also. However, if you can be assured that it will always have been called before the cron job, then you might be able to use the headers approach.

YYoh I have a cron job (the scheduled export in the worker entrypoint) which interact...

cloudkite•10/22/25, 3:06 AM

Nice pattern to handle this is to have init return a RPCTarget with methods you want to be public and make everything else on the DO private. This makes it impossible to access the DO without going through your init fn

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

Yoh•10/22/25, 3:07 AM

I love that!

cloudkite•10/22/25, 3:14 AM

You can pipeline the init call to reduce round trips and it can work out cheaper as multiple methods invoked on same rpctarget instance is counted as single session

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

Larry•10/22/25, 4:04 AM

Are there any footguns with that approach? For instance do such sessions timeout? Or is that a non-issue when calling from a cron Worker? Might it be if calling from another DO?

LLarry Are there any footguns with that approach? For instance do such sessions timeout...

cloudkite•10/22/25, 4:10 AM

If using the “using” keyword

it should automatically be disposed. Unsure about max or idle timeout. Good idea to have wrapper on calling side to do retries with backoff

JJacob Marshall Does anybody know whether a Durable Object is moved back to it's original colo a...

lambrospetrou•10/22/25, 9:30 AM

I answered this a few messages above: durable-objects
Yes, at the moment, DOs will move back to the original colo if it's healthy.

LLarry Are there any footguns with that approach? For instance do such sessions timeout...

lambrospetrou•10/22/25, 9:31 AM

The only footgun is that the RpcTarget might need to be recreated if the connection breaks, but if you create a new one each time it should be OK.

Llambrospetrou I answered this a few messages above: https://discord.com/channels/5953179901913...

Jacob Marshall•10/22/25, 10:16 AM

Ah thanks for your response! Very helpful. For my use-case it would actually be more ideal for the DO to not hop around to be closer to the requests. I know that sounds unintuitive, but I’m building an app where the choice of location is intentional, and it may be possible that requests may come from customers from anywhere in the world - and moving the DO due to a high number of requests from a distant location would be not ideal. Happy to get in touch directly for more info

JJacob Marshall Ah thanks for your response! Very helpful. For my use-case it would actually be ...

lambrospetrou•10/22/25, 10:44 AM

Yeah, I doubt something like that would be released without some flag or at least some control for the users. This is mostly long-term vision.

Llambrospetrou Yeah, I doubt something like that would be released without some flag or at leas...

Jacob Marshall•10/22/25, 11:01 AM

That’s a relief haha. Thanks for the info!

Llambrospetrou The only footgun is that the RpcTarget might need to be recreated if the connect...

Larry•10/22/25, 11:29 AM

If you re-create every time, do you lose the promise pipelining fewer round trips benefit?

LLarry If you re-create every time, do you lose the promise pipelining fewer round trip...

lambrospetrou•10/22/25, 11:33 AM

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...

lambrospetrou•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.