You can use location hints to "hint" that it should be within a specific region: , as well as restricting objects to a specific jurisdiction (like for GDPR), but nothing direct to a specific colo. Not all colos support Durable Objects either ()

thank you. that helps.

Does anyone know if a DO connects to another via websocket, will they both stay open until one of them closes the socket connection, or will they shut down after no external requests have been made to them?

Is there a possible race condition if 2 requests call

idFromName

with the same never-before-used name? Or are there guards around that?

I've tested that and it was fine, the first one (1-2ms apart) got it, and if my memory serves me right, idFromName first checks with a global coordinator before "assigning" it to the closest colo, hence the increased perceived latency of the first request

I'm assuming all colos have a map of ids stored so subsequent accesses are faster, so it's just a first-time thing

the lookup is cached, but if you don't call

idFromName

with that name in a while, it'll naturally lose the cache and have to look it up again

So you think the global coordinator is able to ensure only 1 DO by name exists, even if 2 requests come in at the same time for a new name? Thank you for your feedback. I'll also be sure to test it, but that's good to know. It's interesting

idFromName

doesn't return a promise since it can be async.

That’s because the check doesn’t actually occur until the stub is fetched the first time

Ah. So if a worker in NA calls

idFromName('new-name')

and a worker in EU calls

idFromName('new-name')

at the same time, they'll both have different ids. When they call

fetch(req)

will they both get a different DO instance, or will the system ensure they are routed to the same DO? I'm looking at using the DO mechanism so that multiple players of an AI text game who are hitting the same un-generated branch of that game will be able to request it and have a unique DO for that branch ensure the request to generate the AI response only happens once and is returned to both players and caches the response in R2 for future players who go down that particular branch. I'm not sure if the guarantee for 1 DO in the world for a given name extended to this case when 2 clients could be asking for the same new name at the same moment.

The intention is that the initial NA and EU

idFromName

calls will meet up somewhere in the ether and one will win so that there will only ever be one DO that matches that "name". This cross coordination occurs before a fetch can be called, so they will be "routed to the same DO". That said, I don't know if anyone on this channel has seen the actual code and sequence diagrams that confirm it achieves this intention, but if it doesn't work this way, it's a bug, not expected.

you don't need global coordination to get a consistent id from a given name. the docs already say it's deterministic https://developers.cloudflare.com/workers/runtime-apis/durable-objects/#deriving-ids-from-names "will always return the same ID when given the same name as input"

you need global coordination to know the exactly 1 place it can be running

Might have asked this before, but any plans to have a way to get the current “region” from within a DO?

aside from the previously widely discussed unsupported hack that will likely be removed, no

Do tell?

👀

I’m just wondering for having a regional coordinator, it would be nice to know “this DO is in ENAM”

i just mean cdn-cgi trace

I don’t need the exact colo, just the locationHint region

don't count on that working the same way in perpetuity

I get that

oh locationHint region as opposed to the actual region an arbitary DO is running in?

Maybe on the ID, have a location property with the region attached. Doesn’t have to be the region provided when creating the DO, just the region the DO was actually spawned in

or the equivalent naming convention as locationHint, regardless of whether you gave a hint?

This one, I think. I don’t need it externally available, it would just be nice to have a DO be able to recognize that it spawned in North America(or whatever the region code is)

what's the use case?

Having a regional coordinator for a group of DOs. It would allow the DOs to communicate from one region to another efficiently, without manually having to have connections to/from every DO

Also to apply filters to incoming messages at the regional level. Basically, a message bus, where instead of having every DO process every message, then instead have a few regional filters, that then pass to the individual DOs as necessary

I'm using the cdn-cgi hack to create connection pools for each region where DO's reside. Would there be a recommended way to manage pools of X connections for a service?

locationHint

could work. Just need to route connections to a nearby pool. Edit: I have one Coordinator DO for the DO location nearest a Worker request, referenced by colo name. It is in charge of creating new Pool DOs and assigning connections to them and keeping them from being too full or too empty. The Coordinator DOs just need to be close. So I need the information on the Worker request.cf object. The Coordinator name is arbitrary. I could have one Coordinator per Worker colo, but that would be too granular for our size. One per locationHint would work. So if a worker had

request.cf.locationHint

I could manage pools easily that way.