AIt's on VPN to Albania - thought I'd populate the list some more 
Jit would be so nice to be able to send a worker request to a specific colo for testing this sort of thing
Awhen you loaded this page from undefined, a worker in Bucharest (OTP) created a durable object in Vienna (VIE)correct colo this time
Await,
colo=PRGmaybe pager went off : )
Aseems to change a lot from this location
AA- it was 44% when I started
Jdenominator+++++++
AAlright, I "managed" to bring the percentage down to 37. Won't spend anymore time on this 
JJ(tho should’ve handled that more gracefully)
HHow'd I not noticed that? I needed the locations of the datacenters for a project, so I scraped them off the statuspage then geocoded them.
CGuess I should update my latency map durable-objects
Ji did the same until i found that endpoint!
Jgood thing workers makes scraping so easy…
CActually no - the coords in that list are literally the airport coords which makes the map look rather weird zoomed in. I'll keep my reverse geocoder.
HDoes your Latency Map test latency to your datacenters, or the actual Colos?
Cit's measuring roundtrip latency client – worker – DO – worker – client using a websocket connection (as we do for our "real" apps)
HAnd how do you figure out which colo the DO is in?
HShould have foreseen that.
C
CHmm, curious. One of my DOs moved from LAX to SJC today 
Is that supposed to happen?
Is that supposed to happen?HMight have been me...
HSorry about that, @codefrau!
CHuh? How? Supposedly DOs are fixed to one colo, unless that colo is down, I thought
HI believe that DOs persist in one colo, until they are shut down. Once they are triggered again, they are reinitialized in the nearest DO-ready colo to the incoming request.
CThe way @kentonv_cf described it is that it lives in one colo, but is replicated to a few near colos for backup. It would not "jump" from the EU to the US.
HAccording to your log above, it seems that because there was an extended period of time with no requests, it was terminated(FRA). Once someone else triggered it(Me, probably), it was reestablished in the nearest Colo(SJC) to my request.
HAt least I believe so, I'm having a hard time figuring out that log.
CLAX being down for a while would make sense, but I'd have assumed it would move back to LAX once its up again.
HNot if the next request comes from somewhere else, before it can reestablish itself there.
Cthere were like 13 hours in between
HThe change?
Cto "jump back" from SJC to LAX
C... but maybe SJC is now the "authoritative copy"
HHow many times was it triggered in those 13 hours?
CNever. This is the complete log.
CI left out some detail but the last connection in SJC closed at 2021-08-05 03:22:52.283 PDT
HSo, somewhere within those 13 hours, the SJC Instance was terminated. Then, after 13 hours had passed, someone sent a request, initializing a new instance at LAX
HNot me then.
Cno it's in SJC now
HSorry, meant the other way around.
IDo console logs show up in
wranger tail
EDOs that do not have any external state (used the storage API) can be garbage collected and restarted at some other point.
But if I am not mistaken we did have an issue in LAX recently, so it may have been a fail-over indeed. And SJC being the copy with the data now.
And you are correct in that a DO will not leave the cluster it is currently part of, so it won't move from the US to the EU etc.
But if I am not mistaken we did have an issue in LAX recently, so it may have been a fail-over indeed. And SJC being the copy with the data now.
And you are correct in that a DO will not leave the cluster it is currently part of, so it won't move from the US to the EU etc.
ENo, they do not unfortunately..
IIs websocket to websocket communication possible from Durable Workers to Workers?