what's up with closing?

[ivanjaros]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

I am observing strange behavior on frontend javascript. When I call close method on the javascript websocket, it takes a minute before close event fires. That means closing is not handled by the go backend whatsoever, the connection simply expires. This is not what one would expect. The documentation clearly states that calling close method invokes the closing process where both parties "negotiate" closure. So when js sends close message, backend should respond immediately and close connection. This is not happening, hence the frontend fires close event after a whole minute.

I have called SetCloseHandler() on the backend ws connection to ensure the default close handler is set, but no change in behavior was observed.

This library has been a massive pain in the ass since day one. But since it is the most widely used, I am stuck with it. Figuring out the ping/pong was a journey I'd like to avoid repeating with this situation.

On the backend, I am not reading any messages, it is one-way communication so my suspicion is that reading the close message is not invoked at all because this library does nothing on its own. But I have no way of implementing NOOP reading on my side because no message will ever be received so it would block indefinitely and because there are no channels involved this is a no go solution. Unlike with ping pong where i can temporarily lock writer and set read timeout.

Expected Behavior

No response

Steps To Reproduce

No response

Anything else?

No response

[canelohill]

I am not reading any messages

This is the problem. The package documentation says:

The application must read the connection to process close, ping and pong messages sent from the peer. If the application is not otherwise interested in messages from the peer, then the application should start a goroutine to read and discard messages from the peer. A simple example is:

func readLoop(c *websocket.Conn) {
   for {
       if _, _, err := c.NextReader(); err != nil {
           c.Close()
           break
       }
   }
}

This readLoop function from the documentation does not block indefinitely. NextReader returns with an error when a close message is received, the connection is closed, or there is some other networking error.

[ivanjaros]

OK, adding nop reader seem to have worked. Not the close event fires after couple of seconds at most.