Connection stuck in CLOSING state

[zdila]

Probably it starts with some connection problem: readyState is set to 2 (CLOSING) and close event is never fired. Is this expected?

[lpinca]

No it's not, when ws.close() is called a timer is started to forcibly close the connection if the other peer fails to work properly.

Is there any way to reproduce this?

[zdila]

But we are not calling ws.close() in this case. readyState gets to 2 probably because of network (or remote server) problem.

[lpinca]

Yes but readyState is set to CLOSING only when the connection is being closed (1, 2).

[zdila]

I'll try to collect some more details then.

[lpinca]

The only thing I can think of is this callback not being called but it's hard to tell why without a test case as it should be called in all cases.

[logidelic]

I believe I'm coming up against the same issue. I was investigating why my websockets were closing (on the client side) unexpectedly in some cases. While investigating I noticed that not all server-side connections end with a "close" event being emitted. Perhaps, as with the OP, this is because the connection got closed due to some network failure (still trying to figure that part out). In any case, however the ws closes, obviously the server needs to know about it.

Is there any workaround for this? I guess I could poll the readyState, though that's a bit lame...

[lpinca]

@logidelic you issue seems more in line with this FAQ: https://github.com/websockets/ws#how-to-detect-and-close-broken-connections

Is the readyState stuck on CLOSING for more than 30 seconds in your case?

[logidelic]

Thanks for the response @lpinca. Some notes/questions

• My client (regular chrome websocket) pings the server regularly, and the server responds to the pings with pongs. My client will detect an unresponsive server and close the websocket (and try to reconnect).

• I don't really care if the server is unaware of the broken connection right away, but I was assuming that eventually (i.e. when the browser closes that websocket connection with the server or if the browser window is closed), a "close" event would get emitted on the server-side for that connection. Have I misunderstood?

Is the readyState stuck on CLOSING for more than 30 seconds in your case?

Yes, I believe that the "close" event never gets emitted in certain cases. I will debug further to to confirm.

[lpinca]

My client (regular chrome websocket) pings the server regularly, and the server responds to the pings with pongs. My client will detect an unresponsive server and close the websocket (and try to reconnect).

I guess you are sending a text or binary frame as ping because afaik there is no way to send ping frames from the browser.

I don't really care if the server is unaware of the broken connection right away, but I was assuming that eventually (i.e. when the browser closes that websocket connection with the server or if the browser window is closed), a "close" event would get emitted on the server-side for that connection. Have I misunderstood?

Generally this is true but there are cases where there is no way to know that the connection is broken. In these cases the connection is technically working and OPEN on the server and that's why you need an heartbeat system.

Anyway if your connections are stuck in CLOSING for more than 30 sec then there is a bug.

[logidelic]

Yea, I'm using sending my own ping/pong text. I will test further and report back about the closing state.

[rsarili]

Hi, I coming up with similar problem, my connection readyState stucks in CLOSING state when server close the connection. Here is my test case,

• client connects to server
• after some operations server close the connection
• client side got the close event
• I expect close event should be emitted in server-side too. I run server from localhost and from Azure service. In localhost it works but, in Azure service connection readyState stucks in CLOSING state for 30secs. I am not sure if this is a bug of 'ws' since it is work in localhost. This test case result every time like that, so I am not sure if it is a network problem. Do you have and idea of the reason? and Can you suggests to way handle that?

[lpinca]

@rsarili since you have a way to reproduce the issue it would be great if you can verify a couple of things:

1. Check if this callback is called and if _closeTimer is set.

2. Check if this callback is called.

[rsarili]

@lpinca Latter callback is not called in stuck case. It is called after 30secs

2. Check if this callback is called.

[lpinca]

Wait, maybe I misunderstood. In your case is the connection stuck in CLOSING state indefinitely or just for 30 sec?

If it's only for 30 sec then there is no bug and it may be a network issue where the client fails to send a FIN packet to the server.

[rsarili]

it is for only 30 sec, is there way to check FIN packet from code?