try setting the binding for each env separately, e.g. for prod [env.prod.durable_objects]

Ah that is possible to do!? 😄 I'll try that immediately 🙂

Thank you @User !!!

@User this could probably be added to the docs 😄

Can you post in #773221328182050826 what you would like to have added?

Sure thing

ahh, this one got me too - and this channel seems to be the only source for the solution thus far! +1 to a docs addition 🙂

@User Do you have time to look at those questions from Friday? I'm still not sure of the implications of your suggestion.

Missed those. DO is created close to the thing that created it. So if you a DO creates another DO it will always be in the same location. (Barring things like jurisdiction). But if the code DO returns back to the edgeworker that invoked it, and the edgeworker creates it, it will be created close to all users.

Does that make sense? So edgeworker -> codeDO -> edgeworker -> userDO

ok thanks, so it sounds like my current setup is optimal wrt having the game-server DOs close to the users. The only thing I'm not sure of now is how the chain of websocket works in the hypothetical codeDO creates the gameserverDO case - does the codeDO proxy the websocket, or is it more like a handle that's returned and the edgeworker talks directly to the terminating DO?

Maybe I am misunderstanding things, but I am pretty sure you dont want the codeDO to create the gameserverDO?.. if the edgeworker creates it after the call to the codeDO, it will be created closely, and you can pass the websocket connection through it?

Oh, this is just for my understanding of what's going on. You're right that I wouldn't want to do this in this situation.

That's why I said "hypothetical" 🙂

Hey. Durable Object instance is always bound to one specific Worker? In contrast to KV with id, I can use it and access the same data from several different workers. With combination of workers not allowed to call one another, this is a bit disappointing..

The DO itself is always one specific Worker. It’s kind of stateful Worker, only one instance of specific DO id is running, but it can be accessed by any other Workers, same as KV they just need to bind the DO namespace.

thanks for reply. So when I'm, binding, I'm doing something wrong. Errors happen, if I won't publish --new-class

@User yes, and you need to do all your --new-class and --delete-class options in one go - otherwise the whole deploy gets rolled back

in case you want to add the binding only as your DO is attached to different worker already, just add

script_name

to the wrangler configuration, e.g.

[durable_objects]
{ name = "BINDING_NAME", class_name = "ClassName", script_name = "worker-script-name-the-do-class-is-attached-to" },

alright. I'll investigate. Thanks

hahA! Now that when I read it third time, I got it! 😲

it's the actual filename of the script? I have this build system, that separates them. But, I'll just try it all.

What is your setup? Do I get it right that you are trying to bind the already existing DO to different Worker?

I create compositions; I fetch code from several sources (I control them), and then rollup.

There I dev or publish. Generated worker has siblings, and they share some/most of the code, like libraries

the published worker is just type "javascript", so the basic examples usually just works

So if its one Worker with the DO class, then you need to add

--new-class

for the first time, as @User suggested, to tell Worker there is a new DO class to attach.

Described also here https://developers.cloudflare.com/workers/learning/using-durable-objects#uploading-a-durable-object-worker

yeah, thanks. Durable Objects have been fantastic so far. I have been experimenting with them for some time