The change?

to "jump back" from SJC to LAX

... but maybe SJC is now the "authoritative copy"

How many times was it triggered in those 13 hours?

Never. This is the complete log.

I left out some detail but the last connection in SJC closed at 2021-08-05 03:22:52.283 PDT

So, 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

Not me then.

no it's in SJC now

Sorry, meant the other way around.

Do console logs show up in

wranger tail

for durable workers? Doesn't look like it 🤔

DOs 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.

No, they do not unfortunately..

Is websocket to websocket communication possible from Durable Workers to Workers?

Will DO's be able to migrate themselves at some point?

That is certainly part of the vision for DOs, but that won't be part of the first release I would imagine..

Probably a bit of finagling to get it GDPR-Compliant...

I'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 Any tips? Is this at all possible?

It 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.

I don't have a lot of experience with the websocket side of things @User, but I feel it should absolutely be possible?

On the finagling, I meant getting the auto-migration to be GDPR-Compliant.

Oh no.. that is the easy part for a change 😄 .. the technical challenges are way harder tbh..

My brain hurts just thinking about it.

So does mine, so I am glad we have an amazing team working on that tbh.. 😉

So 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?

I'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.

That is correct. (Assuming it saved something to storage). If it didn’t save something to storage I believe it could.

Actually, I think I just made it work 😮

Is there are a package / endpoint to make the

colo

field more human readable?

I 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