But having an IaaS like KV to handle it with Workers serving it on the frontend, sounds much more managable, bearing Cloudflares latency to Twilio is minimal.

Which I would assume isn't an issue 😄

I'm gonna setup a test, thank you so much!

I see. So the behavior you're seeing is expected - Durable Objects won't be killed on an unhandled exception, so your other websocket connections will stay connected. If you want to observe the error, you'll need to await the function - otherwise the error may not have actually occurred before a response is returned to the eyeball worker.

Thanks got it. Was wondering in general if the DO would be killed on any error.

From their open beta announcement blog post, DO would bill differently for when it is using CPU versus when it is idle as a connection is keeping it alive. DO won't be billed otherwise. https://blog.cloudflare.com/durable-objects-open-beta/

So, today there's no charge because we're in beta and we're still working through the answer to this for WebSockets. Once the last request finishes processing, you immediately won't be charged further. You're billed wall-clock time, which means you're billed for the number of ms spent responding to the request, including time spent waiting on subrequests or storage I/O. There are open questions here around mostly-idle WebSockets (since those hold a long-running connection open to the DO), which we're still addressing.

Thanks. It seems to me that the optimal charging scheme might be: 1) Active, executing code or awaiting a fetch (external, KV or Storage) request - charge per ms at the full WU rate. 2) Inactive, waiting on idle WebSocket - charge at a lower rate. 3) Sleep, after a delay after the last request/WebSocket connection finishes. Only charges for 'durable' data written to storage. I wish (1) was "Active, executing code" without awaits, but we can't always get what we want 😉 I suppose the design goal of DO is that the spin-up/activation delay from (3) to (1) is short enough that users don't have to worry about it.

What would be the correct way to have the DO do a background job? Example, fetch into a DO to queue a job. Returns OK queued. DO has 0 connections, the job that just got queues needs to be synced in the background to another endpoint. Then sent to another DO for processing.

Doing all that in the initial request before returning will be unrealible and too slow

If you are inside a await, and another websocket connects, will it be able to?

To a DO

Will it proc in parallel as the await yields to it?

Why are DOs only accessible through a Worker? Double-dipping on request billing? 😉

heres a question on pricing, is wall time priced per connection?

I think DO's are inherently single threaded, so I can't see how that billing could be per connection.

what im trying to say is having only 1 connection leads to some real expensive wall times

yeah, I think the WS blog talked about that this week: https://blog.cloudflare.com/introducing-websockets-in-workers/ "Pricing Considerations"

> We’re currently working on the best way to price WebSockets that are terminated in a Durable Object. > > Our current thinking is that when using WebSockets, you'll be charged for wall clock time whenever a message is being processed by the Durable Object on any WebSocket connection - this charge would be shared across all WebSockets connected to a given Durable Object. When there is no CPU activity on a Durable Object, but any number of WebSocket connections remain established, you'll be billed a much lower active connection charge, per second.

ohhh i see now

so it only counts wall time when a message is being processed

but that raises the question, how do you know when a message is being processed or not

..... "trust us, we'll only bill you when the CPU is busy" ?

another DO question: am I able to upgrade the DO codebase and maintain contents of the durable storage, or do I need to wipe and recreate the DO objects fresh every time?

i believe the DO is reset upon code change

wait, really? so there's no persistence whatsoever?

that seems really surprising?

im not 100% sure

ive not tested it

but i know existing connections such as websockets are killed upon DO change