Simply because the amount of work each packet takes is negligible at best.

It is a potential problem indeed. Especially if you do a lot of processing in the DO.

Hey 🙂 I am seeing increased

Error: Network connection lost.

DO errors (after 3 retries), something going on?

I see those a lot too, but I always have. I was assuming/hoping that it's because I'm deploying fresh versions frequently

Also, is this a transient thing within Cloudflare? More specifically, is it worth retrying worker->DO connections?

I was experiencing random errors in small percentage of requests before, which I resolved with retries after recommendation. Since then, any peak in errors means something might be wrong with Cloudflare, and it was in yesterday's case as well. (its resolved already) If its worth to retry these connections/requests in the beta period is completely up to you 🙂

well, if it annoys me enough I'll definitely add them to remove that friction - right now it's not worth the hassle!

Is there any performance benefit to using

idFromString()

over

idFromName()

? I'm connecting to a coordinating DO before I get to the main DO, so I could cache the ids.

Also, once a DO is created, is it always recreated/rehydrated/whatever at the same edge location?

Mostly, but not guaranteed. For example in the case of a fail-over of the data center

And also, "Cloudflare will automatically create the coordinator close to the users using it and migrate it as needed, minimizing latency." Right? https://blog.cloudflare.com/introducing-workers-durable-objects/

Automatic migration isn't implemented yet, but it is indeed one of the things that we want to do..

Hmm, so this permanent DO that I've created will be near my current location, not near my users. If I delete the worker I assume new DOs will be created with new IDs and new locations?

Not sure I get it. If you use newUniqueId() it will always be created closest to the user of that Worker?

By "permanent" I mean a global singleton DO that all sessions connect to. My flow is that the user either selects new or enters a char[5] code. This coordinating DO either generates a unique code or verifies the supplied one exists. If found/new, the user then connects to a second DO using idFromName(code). It's the physical location of this coordinating DO that I'm talking about.

I'm currently near Singapore, but the users will be in Europe/nAmerica so I don't want this coordinator on the wrong side of the planet!

Ahh.. yes, all sessions would live in that one data Center. You don’t just need to delete the worker, but also the DO class I would think.

ok, thanks. My final version will be idFromName(apiVersion + code) so I guess I can just make a new DO later from Europe. Do you know if there's any performance benefit to using idFromString() over idFromName()? Again, this is to (prematurely) optimise this singleton access.

No, I have only used Name. I would imagine that String is an alias for it? Could be an old name that they kept for backwards compatibility reasons or something?

It's a different parameter - id takes a hex encoding of the id that is returned from idFromName(). So, I was wondering if that skips some kind of nontrivial lookup. Tbh, this is definitely premature given that this stuff is still in beta 🤓

Oh naw.. doesn't look like it. But btw.. I was just thinking, why do you create the new DO from the Worker instead of the central DO?

because I want the new DO to be close to the user as per usual - the first DO is just to manage the codes. I'd assumed that if a DO started a new DO then DO2 wouldn't know anything about the original requester and their location...

I'm also using websockets and I don't know how that would affect things - I wouldn't want each message to have to go edgeWorker -> codesDO -> gameServerDO and back again

Hmm, how *is *the location of the DO decided? Does it use the information in the ​ IncomingRequestCfProperties or something, or is it just based on internal routing/load balancing?

https://tenor.com/view/alice-in-wonderland-wonderland-alice-curiosity-trouble-gif-7492639 Down the rabbit hole!

Hello! I have been working on a project using DO now for a couple of months and I'm just about to start beta testing the project in a production environment. However I'm getting into problems with DO. In test environment everything works fine and dandy, but in production environment I simply cannot access the Durable Object Class at all. I.e when trying to create a new DO id with env.INCIDENTS.newUniqueId({jurisdiction: eu}) I get an error like: "TypeError: Cannot read property 'newUniqueId' of undefined" I feel like I have tried googling just about everything and I have tried deleting and creating the do class over and over, removing the entire worker in between. Someone that has any input on my issue? 🙂

It looks like your binding isn't set properly?

This is how it looks: [durable_objects] bindings = [{name = "INCIDENTS", class_name = "Incident"}]

I'm doing this in mjs with rollup and I have access to the env parameter in this part of my script

I also tried this: bindings = [{name = "INCIDENTS", class_name = "Incident", script_name="prod-script-name"}]