If i'd do the following in my worker:

ts
const id = crypto.randomUUID();

export default {
 fetch: handleFetch(id)
}

compared to:

ts
globalThis.id = crypto.randomUUID();

export default {
 fetch: handleFetch(globalThis.id)
}

Is there a difference in scope? E.g. is the first one scoped to the Worker, the second one to the isolate? Or is it essentially the same? 🤔

Pretty sure it's the same. One is private to the module, the other is stored on the Worker object. So if you had other modules you were importing, the visibility is different.

Anyone get bumped into not able to delete a worker project if associated durable object is still presenting? I tried deleting it with wrangler publish --delete-class $ClassName but it's not working...

I ran into something like this a while ago.. if I remember correctly what needed to be done was remove the binding from the

wrangler.toml

file, then run the

wrangler publish --delete-class $ClassName

cmd and finally delete the worker.

I've done the same but it's still not working. It would be nice if there's an way to explicit view and delete associated durable objects like kv.

@User Btw, did the migration script specified works in wrangler.toml? I've seen it included in some worker project template, but it didn't seems to do anything.

I still need to specify --new-class --delete-class in wrangler.

Also, you can delete classes via the API too, if you are really stuck.

You mean with cloudflare-api? I'll dig into that! Thanks for mentioning.

https://github.com/cloudflare/workers-rs#durable-objects That's the one I saw with migration.

The migration stuff is cool. It should be live in the latest RC, I don't remember if there's been a full release since it was merged

Thanks buddy!!!

No problem, happy to help!

Thanks the cli worked really well! Onward for more durable object testing haha.

Happy Coding!

It's live in 1.19.3, working on getting the docs merged today

The API guarantees that any bindings uploaded with your script have a durable object class to bind to, so you have to delete the class AND remove the binding at the same time. It's actually somewhat redundant that we require explicit bindings for durable objects used and defined in the same script, which is why things like this crop up. We want to make this implicit, but we're working on the right interface for it, it feels a bit too magic for the implicit binding to show up under

env

which is quite different from all the other things in there.

> Does the same mechanism that instantiates it also take care of GC-ing anything allocated in that JS instance? Is it just normal js gc for no longer referenced object instance? It's just normal JS gc > What if something else in the global scope has a strong handle to it? like something in global scope holds a reference to something in the ~~actor~~DO's state? That'd keep it from being GCed

Thanks - it would be great to be able to configure instance eviction notices sent to another DO, kind of like a dead letter queue. Also, what is an actor??? : )

Wasn't Actors the project name for Durable Objects?

Any new updates to DOs?! 🙂

As @User mentioned, internal project name for DOs. We were going to call them that originally, but it's a bit confusing for folks familiar with the actor model

What would you do in response to eviction notices?

Tracking isolate-sharing in real time, to distribute state if necessary to have predictable usable memory (see the long conversations in the scrollback about resource squeezing when you get unlucky). It's great to hear eviction is normal JS gc, so probably will be able to detect it post-eviction by another DO instance and a global

WeakMap

, but it would be great to get a push notification to be able to kick off processes or accounting in real time.

this is the sort of thing where it’d be very difficult to guarantee reliable delivery of that notification, and it’s hard to think of usecases that’d be OK with that. we do want to improve the predictability of isolate sharing, we’d prefer to make our scheduling better than ask you to work around it.

> we’d prefer to make our scheduling better than ask you to work around it. That would be great too! The randomization change from a few wks ago helped quite a bit in this regard. But the situation always is looming where too many large DOs (in memory terms) get put into the same isolate and behave differently (perf characteristics, number of connections, lower in-memory indexing etc) than they would without as much sharing. Maybe you could use the runtime history of allocation per object-id and try to avoid putting the larger ones together in future scheduling? Anyway, it's a tough thing to balance, thanks for prioritizing predictability!

Does durable object accepts request body? I was not able to get it working.

Yep, what did you try that didn’t work?

Maybe rust related, but here's what I tried: 1. construct request_init request_init.with_body(body).with_method(method) 2.build a request with request::with_init($url, init) 3. stub.fetch_with_request(req) No matter what I put in the payload, my durable object won't pickup the request. However if I try stub.fetch_with_url(url) then it worked. Just want to make sure everyone else(non-rust) is able to request with body before I report it to the rust library.