my expectation is that any code updates, whether it's runtime or your javascript, reset all in memory state

the alternatives are really hard to reason about

Oh, so WebSockets are still handled by the Runtime?

yes

ok, so I based my logic on the chat application. I have this. The idea is that each client is sending data to the connected clients as that data is coming in.

ts
    const session = this.sessions.find((s) => s.streamId === streamId)

    while (true && reader) {
      const { done, value } = await reader.read()

      if (done) break

      console.log('sending to client', value)
      session.socket.send(value)     
    }

it seems that the

session.socket.send(...)

doesn't actually execute in realtime, but rather, the reader must be done first before sockets are updated.. 🤦‍♂️

If

Worker A

receive streaming data, it doesn't seem to send anything to the socket (as shown above) until the streaming data is stopped. I don't know if that makes sense

As an idea on the hibernation topic, what if the web sockets connect to something outside the isolate (so it doesn’t need to reset on code updates), and also doesn’t need to keep the DO in memory. Then have the worker / DO receive a binding which represents the connected sockets?

As a user of DO, I believe it is easier to reason about code updates if my code updates reset all inmemory state, including connected websockets and the data attached to them. I'm aware of the concerns about reconnection floods, but I believe there are other more general possible solutions such as gradual rollouts to address that problem (which is also an issue for non-websocket use cases). We're still talking about this, and might revisit an option to keep websockets connected across code updates later, but current consensus internally seems to be we won't pursue it for the initial version of websocket hibernation.

I'll trade even more persistent connections for a er hibernation rollout any day of the week

it'll still be a while, just wanted to get the docs out there for comment

@HardAtWork I updated that docs PR, lmk if that's clearer about the impact of code updates

I made a sandbox of what I'm trying to do: https://codesandbox.io/p/sandbox/kind-dawn-tczmhn?welcome=true in

broadcast.do.ts

on line 45 I left a comment that

socket.send(...)

has no effect. It's not clear to me why worker has to return a response for the socket to send.

Hey guys, I'm sorry to bother, but I'm having a bit of a weird issue with durable objects' websockets: I have my local setup with Wrangler working correctly: one software I do not control connects to my worker that redirect the route to the DO, that creates the WebSocketPair and connects correctly, plus the software sends the messages correctly and the local environment DO reads them. I deployed the same code on Workers, it seems like the WebSocket connection is established correctly (I have the logs were the http request is cancelled), but the DO just doesn't receive any message. I tried also setting up a local node "proxy" that opens a WS server, on connection open a WS client to the DO and then forwards all the messages: the DO doesn't read/receive any message :S What am I doing wrong?

What makes you think the DO is not recieving messages?

logs are not showing in the

"message"

event Listener

and ofc, nothing is run in the function that should change data and interact with other DO

Logs for DOs don't show up until the websocket disconnects. Could that be causing what you're seeing?

Ah that is weirder

nope, when it disconnects I see all the logs of the functions that go up to the

addEventListener

, but not those in the Listener function

Oh that's strange... So just to confirm, the same code that works locally using miniflare (=

wrangler dev --local

) works, but it doesn't work on a deployed worker?

Does it work with

wrangler dev

?

mhm I need to check without the --local

but the same "code pattern" I used for this WS works perfectly in another DO. Just the function is different. I tried connecting to it also via Node using the

ws

library, doesn't seem to work (while the other DO works) The only way I can seem to get the message to read in the DO is using Postman tester

At what point does a Durable Object cease to exist? The docs have a brief message about lifetime, but it's not clear if that just means the DO isn't 'running' and that if you call it by id/name again you'd still be able to access any storage persisted in it.

It ceases to exist after it is evicted when it doesn’t have anything stored

Does that mean if you have a loop creating an alarm every 10 seconds, just like what's mentioned in the DO/alarm blog post that it would technically last forever? (https://blog.cloudflare.com/durable-objects-alarms/)

that post is setting a new alarm in response to a fetch request

no incoming fetches, no new alarm being set

oops, you're right, read more of the post than the code and misinterpreted it

good, then at some point with no future requests it should cease to exist