if you want worker B's MY_DO binding to refer to worker A's implementation of MyDO, your binding in worker B's wrangler.toml needs to look like

is "script_name" refer to the name of the worker?

yeah

like the first line of the wrangler.toml for worker A probably has a

name = "worker-a"

line or equivalent

I'm trying that now

thx for the suggestion

Related to the above, I maybe have gotten to use the same DO, but I'm unable to test it. I'm basically using the DO to be able to track connected websockets in a kind of publisher/consumer. So: Worker A receives a stream ---Durable Object --- storage = [websocket1, websocket2] -----------------------

Worker B

Consumes a stream from

Worker A

When a websocket connects to

Worker B

, I save that socket connection in the DO

ts
await this.storage.put('ref', webSocket)

But for some reason, If I change the above to:

ts
webSocket.send('this executes')
await this.storage.put('ref', webSocket)
webSocket.send('this line never executes')

does something happen behind the scenes from the await call that prevents the execution of the next line?

I'm not clear on what benefit you're trying to get from putting a websocket in durable storage - even if it was serializable, getting it out of storage later after a DO was evicted from memory wouldn't somehow re-establish network connections from the client

Would be cool to be able to store WebSockets in a way that allows you to persist it even if a DO is evicted

What I'm trying to build is a relay: Client streams data - to worker -> worker relays that data to a connected client.

What I thought that I can do is have to workers: - Worker A: To receive data - Worker B: To stream data I thought that I can use a DO to keep track of clients that are connected to Worker B so that Worker A can stream to those clients whenever they connect

I'd love to see this with hibernated websockets, so we don't cause a flood of reconnects if we push a new deployment to the worker - possibly not even changing the DO code.

so after multiple code pushes you would expect to have an arbitrary number of versions of your DO code running simultaneously, based only on which instances happened to end all open websocket connections at a given time? That sounds really hard to reason about

According to the docs PR, looks like it should do that natively

Though I’m wondering if it can persist between

workerd

releases…

Is a hibernated websocket still linked to the specific deployment of a DO class?

My idea was that hibernated websockets can wake up in a new version of a DO if there is one since it was hibernated

What language in the docs PR is leading you to infer that?

What would your expectation be if the new version of the DO has changed how it handles the data in WebSocket.attachment

Hmm, I guess migrations would be overkill to "version" handlers, so not sure really

If the main concern is flood of reconnects, would an option to increase the time for all DOs to reset after a code update not address that concern?

It definitely would if the deployment can define if evicting old DOs is an immediate priority or can be done anytime

This would be with the hibernation API, but that still counts as Native, no?

Thanks, I can see why that's confusing

We are definitely not intending to guarantee that hibernation keeps websockets connected across code updates (whether it's your code or runtime restarts)

I get that there isn’t a guarantee on that a WS is persisted, but is there a chance that it may stay up?