And how do you figure out which colo the DO is in?
And 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 for durable workers? Doesn't look like it
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?
HWill DO's be able to migrate themselves at some point?
EThat is certainly part of the vision for DOs, but that won't be part of the first release I would imagine..
HProbably a bit of finagling to get it GDPR-Compliant...
II've tried this in multiple ways now but can't get it to work. In short, I have a worker which manages incoming websocket connections for GraphQL subscriptions. Once a subscription comes in for a specific chatroom, a connection needs to be opened (or forwarded) to that durable object of that specific chatroom.
- The fetch method of stubs don't seem to return a webSocket, created and passed down as response on the durable object.
- I can't seem to pass a websocket to the durable object
EIt is already possible to restrict DOs only to EU colos.. https://developers.cloudflare.com/workers/runtime-apis/durable-objects#restricting-objects-to-a-jurisdiction
It isn't possible to automatically migrate a DO after it is created, especially if it has stored data already.
It isn't possible to automatically migrate a DO after it is created, especially if it has stored data already.
EI don't have a lot of experience with the websocket side of things @itswendell, but I feel it should absolutely be possible?
HOn the finagling, I meant getting the auto-migration to be GDPR-Compliant.
EOh no.. that is the easy part for a change 
.. the technical challenges are way harder tbh..
.. the technical challenges are way harder tbh..HMy brain hurts just thinking about it.
ESo does mine, so I am glad we have an amazing team working on that tbh.. 
HSo when you say it can't auto-migrate, does that mean that if a DO is initialize spawned in the US, but later terminated(Not Wiped), it can never be recreated in Europe?
II'm not so sure about that, I think the tricky thing is is that the connection comes starts in the Worker. The Worker creates and start's listening to WebSocket events with the client. Once a websocket event comes in that subscribes to a specific chatroom channel, I need to somehow communicate from the Worker to the Durable Object in real-time.
- I can't start a client / server from the Worker since there is no way I can pass the client in a Fetch request to the Durable Object.
- I can't start a client / server from the Durable Object, since the response of the durable object with fetch, doesn't include the webSocket.
EThat is correct. (Assuming it saved something to storage). If it didn’t save something to storage I believe it could.
IActually, I think I just made it work 
IIs there are a package / endpoint to make the field more human readable?
JI believe they are standard IATA airport codes (https://en.wikipedia.org/wiki/IATA_airport_code) but that list posted yesterday (https://speed.cloudflare.com/locations) would be a nice cf-specific endpoint to use, for as long as it's around
An IATA airport code, also known as an IATA location identifier, IATA station code, or simply a location identifier, is a three-letter geocode designating many airports and metropolitan areas around the world, defined by the International Air Transport Association (IATA). The characters prominently displayed on baggage tags attached at airport ...
IThanks that helps, I think I'll try a simple free API reverse geocoding API for now, see how that works.
WAny plan to activate any DO here on SouthAmerica? It’s bad to always be routes to US … that ads to much latency that makes hard to test our software for any regression.