Agree, I love them, truly allows to do stateful magic on the edge 🙂

Huh,

socket.readyState === WebSocket.OPEN

is always true as both are

undefined

for some reason...

I'd noticed that

socket.bufferedAmount

is undefined too. Are they some custom implementation?

Almost certainly yes.. Could you DM me what you are trying to do with a bit more detail? And I'll forward it to the storage team?

Thank you again @User and @User from yesterday. My mental-model of DO just wasn't correct, even though I have been using them from the start of public-Beta.

I didn't understand, that the durable_objects property script_name is the name of Worker, the same that is found from eg. listed in dashboard of Workers page

Now it works, and I can use the same DO from different Worker, and from different DO. Very flexible

I agree that "script name" isn't the best name - while it is all packed into one file for the deploy, it's not really how people think of them. worker_name is probably a better choice

I agree. That diverted me, when no actual documentation was available

Happy to help! And yeah, I had similar struggle in the beginning 🙂

What are you doing that will need multiple DOs talking to each other across workers? Anything fun?

well, almost all coding is fun for me.. but other than that, I have a microservices ecosystem on aws, and the moment I saw the first info about DO, I was sure I will investigate it and most likely make the switch. I'm still in prototyping, but it's looking good.

aws has many great qualities, but with Workers+KV+DO + Google Cloud Run + something else, I have a great opportunity to lessen lots of configuration and make things fast and simple.

with aws, low cost, fast, simple, low configuration is really not a think. At least I never found one

So, fun for nerds 🙂 Sounds good.

Can someone speak to when Durable Objects are suspended? And how that affects billing. For example, am I billed only when the DO is answering requests or for the entire time that the DO is 'not suspended'?

Separately, are the results of calling

state.storage.list(options)

method based on an index - e.g. how performant is it to call that method on millions of keys?

to clarify, not wanting to list a million key/values - rather list 50 key/values out of a million using start/limit

In my testing, the DOs seem to suspend after a few seconds with no websocket connected. I believe the billing is taken on by the connecting worker, but I'm not sure on that (especially since it's still in beta). Not all the costs have been finalised (I'm a bit concerned about long-running websockets but we'll see).

I'm sure the workers team can give you a better answer (the folks in orange)

No.. we can't give an answer that is a lot better @User.. except that billing is still very much in flux, especially when it comes to websocket connections. So right now you won't be charged for anything, but I am pretty sure that if you have no Websocket connections open, you won't be charged for a DO when it is not running.

Thanks @User and @User

Is the Cache e.g.

caches.default

available from Durable Objects as well as workers?

What is the recommended way of dealing with "Network connection lost" errors fetching from busy DOs? It would be great to have more info on this mysterious condition. Are we supposed to do our own immediate retry with exp backoff? Too bad it doesn't do that automatically.

I've seen some mentions of DO having access to the

waitUntil

method (specifically on the

state

object passed in the DO constructor), however, I can't seem to successfully find/use it. Does anybody have an idea as to how I can access the

waitUntil

method from within a DO?

Yep!

I would definitely recommend a retry if they work for your application (we don't do them automatically because you can't necessarily distinguish between a request that made it to its destination and disconnected and one that never made it there) -- that said, we are working to greatly reduce the frequency of these

You don't need to

waitUntil

in a DO, all promises in a DO are effectively automatically waitUntil'd

Yeah, list is efficient to use

Thanks - are immediate retries after this error likely to succeed or should we wait a few seconds? Ideally we'd just retry immediately using a new stub (we use a new stub for every call). Also: would be great to know ballpark percentage of these error requests that actually make it to the DO vs die before - ie is it usually the former or the latter from what you've seen?