10 replies

I see that the worker websocket is

I see that the worker websocket is closing the connection every roughly 4.5 mins. Whats the deal with this? I've not run across any documentation which has some information on some kind of timeout.

Alex•4/15/25, 1:06 PM

Are you sending any data over the connection?

Alex•4/15/25, 1:07 PM

I am trying to see where it's exactly coming from. But WebSockets usually have some inactivity timeout. It might come from the client or the server (or both) and is usually solved by sending ping/pong messages at a regular interval.

zehawkOP•4/15/25, 1:25 PM

No, its a completely idle test. Nothing happening from the client (that's why I tried on Postman as well to remove any dependencies).

As a control, I did multiple tests with echo.websocket.org - that timesout at around 45mins+.

zehawkOP•4/15/25, 1:27 PM

So it seems to be a timeout on CF side, so that begs the questions (a) why is it so low? (b) where's the doc on this (c) is it controllable?

zehawkOP•4/15/25, 1:47 PM

When I do the test with wrangler dev --remotewrangler dev --remote, the timeout is consistently 1 min

boop•4/15/25, 1:50 PM

Try this
https://developers.cloudflare.com/durable-objects/api/state/#setwebsocketautoresponse

Note that you will have to manually send these application level pings from your client

zehawkOP•4/15/25, 2:04 PM

Yup, thanks, thats what I'm adding now to see how the behavior changes

zehawkOP•4/15/25, 2:43 PM

So yes, sending any random WS message at 4min intervals prevents the timeout. I assume that the DO has to keep waking up to handle this, and to prevent that I should use setWebSocketAutoResponse. Is there a working example for this method since the doc leaves a lot to be desired.

boop•4/15/25, 2:45 PM

See this thread:
#Hey

I have a DO based off of this

zehawkOP•4/15/25, 3:49 PM

@boop you are a star, TY for pointing me to exactly what I needed.

I see that the worker websocket is

Similar Threads

Similar Threads

Similar Threads