Yeah, I'm haven't even been thinking about concurrent requests. If a new request comes in while one is in-flight, and the new one finishes before the in-flight one fails, that could be a problem.

Eh, it's subtle but I think Input Gates handle it: > Input gates: While a storage operation is executing, no events shall be delivered to the object except for storage completion events. Any other events will be deferred until such a time as the object is no longer executing JavaScript code and is no longer waiting for any storage operations. We say that these events are waiting for the "input gate" to open.

When you complete awaiting write(s) you should (synchronously) update in-memory state right after

Shucks. Refactoring required.

Better to know it now than later

There is a map of the CF DOs like for PoPs please? I've understood the goal isn't to have 1 DO per PoP, but at least 1 DO per datacenter, so I would like to known how this goal is achieved please

PoP and data center are pretty much the same thing. DOs are only available in a small subset of data centers. You can see where a specific data center will create it's durable objects here: https://where.durableobjects.live/

so cool ! thank you !

About the pricing of DO, could you confirm we don't pay anything is the DO is not active ? For performances reason, we want to pre-create one DO in each available colo, with few KB of data. But then, most of them will never be active until the day of someone closes to this DO will be active.

( I precise, we want to uses idFromName() that require a global lookup at creation )

You said « you can create a DO per data center by using the name of the colo », but as the project https://where.durableobjects.live/ reveals, when you are one one worker/colo and you create a DO, it's not always done one the same colo, sometime it's even in another country. How we could achieve this one DO per data center in theses conditions?

The one colo to datacenter that they meant was that you can have a DO created with

idFromName("BEY")

for the Beirut colo, even if the DO doesn't actually spawn in Beirut.

Ok, but this also mean if it's go to the wrong colo, this will stay on a wrong colo forever, right ?

Example on ALG, you could be re-oriented on 3 to 4 different colos : https://where.durableobjects.live/

Yeah, at the moment it is that way. However, if you can tolerate some downtime, you can kill the

ALG

DO, wait a while for it to be cleared from the registry, and then spawn it again, this time hopefully closer to where it should be.

My oops of the day week month(maybe?): I recently changed the #981314061268578304 that I was using for WhereDurableObjectsLive, but notably, only in the

wrangler.toml

. I'm sat here, debugging why all of the APIs I use are returning no values in the last hour, and then it hits, me: YOU NEED TO UPDATE THE SQL API TO THE NEW DATABASE!!! TL;DR I made a mistake, and now y'all get the actually fresh data. Also, I'm working on an update for WDL. No idea how long it will take, but keep your eyes peeled.

Heyy there's ADB

They may not be placed exactly in the colo you originally call them from, but they're only placed within a small latency bound, they should be close/fast. You can also use

locationHint

to place them in certain regions: https://developers.cloudflare.com/workers/runtime-apis/durable-objects/#providing-a-location-hint

If your the owner of where.durableobjects.live website, I've read your issue ticket #1 ( DNS cloudflare.com vs 1.1.1.1 IP for /trace ), do you believe the current informations in the list could be wrong? ( may be finally there is more accurate colo than reported as wrong )

I am actually wondering why that may be. At first I suspected it may be a difference in plan tiers for

cloudflare.com

vs

1.1.1.1

, but it seems odd then that

1.1.1.1

has the better data. Maybe it is a quirk of some system set up specifically for

cloudflare.com

? Either way though, within a Cloudflare datacenter, both should produce the same results.

Could be interesting to do the 2 requests to compare, and if there is a difference of detected colo, to explain in the report the method... or to ask at Cloudflare what could be the reason of this difference, it's weird indeed

nice work in all case 🙂

In general you shouldn't (can't, actually) depend on requests landing in specific colos

hmmm, I explain my uses , may be I'm doing it wrong so. We have a ecommerce website, we want that each user's data are saved closes to them (for performances + GDPR). For pricing reasons, we want to share a same DO for all customers of this area. I don't mention the req.cf.isEUCountry and juridiction() subnamespace to make it simple So, when a new user need to be added, we need to find the closests DO, so we can uses the idFromName(req.cf.colo) The problem is, if for example the worker colo is ATL/Atlanta, but the DO creation is done at IAD/Ashburn (~19% of luck based on WDOL's data), this mean all the others workers on ATL will always go the the IAD DO, rather the fact there is a DO on ATL too ...

(correction)* « rather the fact there could be a DO on ATL »

What would you recommend then for finding out the current location of a DO? It doesn’t have to stay there, but it would be nice for metrics

I understand the desire to optimize but ATL and IAD are like 15ms apart. What about users that land in one of the many non-DO hosting colos like, say, Boston? Are you sure within the correct region isn't close enough for folks who land in IAD or ATL?

The cdn-cgi hack is all there is for now, all I meant is that you can't depend on an eyeball to land in a certain colo or for a DO to run in a certain colo (just because you saw them there once before)

Just to confirm, the cdn-cgi hack will always return the correct colo for requests coming from within, right(DOs, Workers, etc.)? I’m fine with not being able to guarantee that the DO stays in the same colo, I’d just like to know where it is now.