Wait... with the DO binding I just add the DO namespace, not the Worker that actually use the DO.

Guys... this is very confusing :/

What is the point of adding a DO namespace to Pages if Pages can't use a DO on their own?

Service binding: You can call a workers

fetch

handler. DO binding: You can call a durable objects

fetch

handler directly (bypassing the worker

fetch

handler) Pages can use DOs, it just cant export a DO. Only workers can export DOs.

Ok, but I can't create a DO without creating a Worker too, right? Or is there an example somewhere I can see how to make a DO that is not attached to a Worker and only used by a Pages Function?

Only workers can export DOs

So, in order to export a DO I need to do it like this, with a Worker that handles the DO, right? But if I add a DO binding to my Page, I can ignore the Worker and invoke the DO in a Page Function instead? Can I export the DO without the Worker code? I tried removing the Worker code and only leave the DO, but then it says "You seem to be trying to use Durable Objects in a Worker written as a service-worker". How should I write a DO without a Worker?

You can probably just do

export default {}

and then export the DO. Also make sure you disable the workers.dev route so that you dont get any worker invocations from that

OK! I got it to work. Thank you very much! 😄

You should probably clarify this situation somewhere in the documentation though, about how to use DO with Pages Functions, and exporting a DO with just "export default {}". Especially if it will cost more to do a Service binding.

Noob on DO, exploring the basic counter operation (https://developers.cloudflare.com/workers/learning/using-durable-objects#example---counter) in wrangler 2. When the ID changes (from the query param), why does the state reset, and the counter go back to 0 and I see the message "Script modified; context reset.". I would expect this is the very basic of DO that state is maintained per individual instance of the Counter class. Or is this something special in the dev environment?

I'm guessing the lack of persistence is to do with it being the dev command, you should publish it and try there

Thank you, that works as expected after publishing. (With some puzzling, yet understandable behavior of how state gets updated when operating the same DO from dev and published.)

I think you can do this with advanced mode.. see this example with a remix project running on CF pages https://github.com/remix-run/remix/discussions/3066

I'd be curious where you're seeing >500ms latency difference. On your old body-read-time.albertspedersen.workers.dev repro, with a 10mb file, for me the path /3 is faster than /2 now. /1 is faster than either, but I'd expect that, because going only to a eyeball worker is faster than going through eyeball worker -> DO in potentially another colo. From my location, that difference is on the order of 150ms not >500

Worker in CPH. DO probably in ARN.

$ dd if=/dev/urandom of=10MB bs=1M count=10
10+0 records in
10+0 records out
10485760 bytes transferred in 0.026425 secs (396812110 bytes/sec)

$ for i in $(seq 10); do curl -T 10MB https:///body-read-time.albertspedersen.workers.dev/1; done   
21
24
24
16
22
39
46
24
38
27

$ for i in $(seq 10); do curl -T 10MB https:///body-read-time.albertspedersen.workers.dev/2; done
678
506
668
689
309
722
527
361
528
555

$ for i in $(seq 10); do curl -T 10MB https:///body-read-time.albertspedersen.workers.dev/3; done
337
640
680
661
578
504
578
391
648
770

CPH isn't a DO colo, and I see DOs from your account in 5+ different european colos in the past half hour. Might also be interesting to look at the local wall time difference between those requests (i.e.

; do time curl ...

. I can do some investigation on my own account, have you changed anything about that repro script since you posted it?

Is it correct that the only way to "delete" a DO is to perform a deleteAll (https://developers.cloudflare.com/workers/runtime-apis/durable-objects/#transactional-storage-api) on the storage. Once deleteAll completes what happens to the DO? Does it still utilize any storage that counts towards the quota somehow? (In other words if millions of DO are created and thus deleted, are they still counting towards storage quota?) Will the ID still exist and can one again get a stub using the ID?

deleteAll or equivalently delete on every key, yes. You wouldn't be charged for storage for a DO with no rows. As things work today, the ID may still exist (the relevant piece of remaining state being the location), but that may change in the future. You can still get a stub using the ID, a DO doesn't have to have stored key/values in order to get a stub. There are use cases that use DOs only for coordination, and never put anything in storage.

So this answer "Then, once it shuts down the DO will cease to exist" is incorrect, yes? https://community.cloudflare.com/t/delete-durable-object/296432

what is existence? not trying to be pedantic. If you never call it again, you're not going to get charged anything related to it, and the only state you could observe would be that it's in the same location if you did call it again

Is billing the main thing you're concerned about, or something else?

No not billing - just wondering about lifecycle / reuse of DOs. Ie a DO is created and ID assigned to something, for a while it uses storage, after a while keys are deleted since they are too old (eg logs, messages, notifications, etc). At a later point can that same ID be reused or will the DO have disappeared by then.

A DO for any given id (assuming it's valid) implicitly exists once you get a stub and fetch on it. The only evidence of re-use you'd be able to see today is the location it's running. If you want them to be reusable, they are. If you don't want them to be reusable, I'd like to better understand why (other than location, which I do understand can be problematic).

I totally understand this is weird compared to being able to create and destroy things explicitly

Ahhhhhhhhhh. I see what you mean. If it exists, great. If it has been deleted it will be recreated. Either way the dev shouldn't care (but for the location case, which of course is solvable with the hint).

(Note that I do want them to be reusable, so that once IDs have been assigned all over the place they probably never need be touched)

I re-uploaded the Worker as it had been deleted, but the script should be the same. I just noticed I'm creating a new DO for each request (with newUniqueId), but I don't think that should impact the time much?

So wait, does the persistence apply to names too? Like, if I spawn a DO with the name “kody”, wait for it to die, and then try spawning it again, it will still spawn in the same place?

Or is it only based on the ID?