Ah yes if you do not have a paid zone then requests will be routed to cheaper locations.

this is true for the originating worker, but is it also true for the DO?

As I understand it, it’s only about which location handles the initial request to your domain name. And some locations do not host DOs yet but that’s independent of your plan.

right, but if that's the case why do I see PoPs like KIX? it does support DOs but still sends half of its objects to PRG.

That sounds weird indeed.

@User, would love to get some clarity here. half of my DOs originating from KIX are created in KIX, and the other half end up 8,920 km away in PRG.

Does any one have an example of using list() with Durable Objects?

I cant seem to get it to work

const list = await env.PAGEVIEWS.list({ prefix: 'type:pageviews:domain:test.nl' })

TypeError: env.PAGEVIEWS.list is not a functio

Oh you have to use it on this.storage

Afaik, listing DOs isn't a thing yet

I asked a week back and they said it's in the works.

Correct, you can list items inside a DO's storage, but you cannot list DO ids themselves (yet)

I found that durable objects can be used together with websockets. I also read that max execution time of a worker is 10ms or 30s. I don't suppose all websocket connections need to reconnect every 30 seconds but I also didn't find out how it does work. Could someone please help me understand?

@User I gave a shot at reproducing the websocket behavior you had mentioned a few days ago, and I wasn't able to send an event on a websocket after receiving the disconnection error caused by code updates. If you have a code sample that reproduces it, that'd be pretty helpful.

Note that disconnection of actor storage on the old instance after code updates made it into this week's runtime release

Does this mean code updates clears DO storage?

I don't have a code sample, and I also have not seen that error anymore, but I haven't actively tried to reproduce.

So it should be impossible now to observe side effects from the old instance unless websocket disconnection on code updates has a bug, or playing tricks with long-polling HTTP requests (Which currently we don't immediately disconnect as it might not be safe for all applications to do so).

Right. That's how it should be.

... and the way I'm handling it now (closing all sockets so client reconnects) sounds like the right action.

(I'm pattern-matching on

"send a new request"

in the error message)

No, this is referring to the short period of time after a code update when there are two instances for a single durable object (we have to allow existing http requests to the updated durable object to finish up). Before this week's runtime release, that old instance could still access the DO storage API, which could lead to correctness bugs. Now, attempts to access storage from the old instance will fail

Whew. Ok, that makes sense.

The runtime should be disconnecting for you (It's a hard disconnection, without a close frame being sent)

If you're actually able to send a close frame in response to that error, that's a bug! (our bug, to be clear)

Ah, even better. So you will disconnect storage and close all websockets on update.

yep!

Durable Objects are a bit unique, and no, you don't have to reconnect every 30 seconds. You could keep a websocket open to a DO for a long period of time. Of course, all code should anticipate disconnects and be prepared to reconnect.