Persist DO alive during worker deploy
yeah and as a result, websockets are closed from the DO (acting as a listener of my external node).
It can be very dangerous because the DO listen for a payment through the websocket.
Then, any deploy to the worker kills all the connections. Although alarms could re-open the connections, it can be too late.
@Chaika
5 Replies
You're saying your DO is creating an outgoing WS connection to your "external node" (some other server), and that when the DO is evicted you lose your WebSocket, and can miss messages from your external server?
Why can't your external server make an outgoing request to the Durable Object such that it only returns success if the DO actually processes the request fully? Your DO could be evicted for a lot of reasons besides Worker deployment so what you're describing would be an issue regardless of worker deployments IIRC
FWIW, I don't recall the reason the DO is evicted upon a worker deployment, but if I had to guess it's to prevent version skew between the Worker and DO (in the event that you updated both, and the new worker depends on the new DO).
That said, maybe if your Worker and your DO are deployed in different scripts it won't be the case that every time you deploy the worker it resets the DO?
@Milan, my node provides a websocket, the DO connects to it.
And yeah, currently it seems the only to fix is by deploying into a different worker, which is what I was trying to avoid.
Other option is try to recover the lost state after the reset.
Sure but you control the "node", right? I understand creating an outgoing WS from a DO to some server you don't control, but it's a bit less obvious to me why that's the best approach when you control both the DO and the other server (if disconnects are intolerable). Rather than having some long running task where your DO could disconnect, it would make more sense if your server just sent an http request to your DO when a new event happened, no?
@Milan, the "node" I am talking about cannot do that, it's a cryptocurrency node with a very clear purpose, it's It is out of the question to modify it.
Thanks for your help
I have a similar issue --
- I'm connecting to a websocket with durable objects but I don't control the other end of the connection.
- When I deploy a change to the Worker or DO, the websocket connection is closed as noted in the docs
- In my application, this hangs up a phone call and I won't be able to reconnect
- I'm thinking of trying a blue/green deploy pattern, I guess that is what you all mention above about deploying into a diff worker