How to know that the connection was closed

[matheuscscp]

I have a Goroutine on my server that should return if the connection is closed. How can I know if it was closed? Is there a channel that is closed when that happens or something similar? I'd like to write something like this:

conn, err := websocket.Accept(w, r, nil)
// ...

select {
case <-ctx.Done():
	// do something if the ctx of my function is done
case something: // some event selection expression that happens when conn is closed
	// release resources now that conn is closed
	return
}

Is this possible? Are there any workarounds?

[matheuscscp]

The only way that works for me right now is adding a time.NewTimer().C to this select block and write+read a ping.

[mafredri]

Hey @matheuscscp. I'd say it depends on how you're using the library. One way is to check the error from read operations:

_, _, err := conn.Read(ctx)
if err != nil {
    if status := websocket.CloseStatus(err); status != -1 {
        fmt.Printf("Connection closed with status: %v\n", status)
    }
}

Or alternatively, if you don't read messages, you could listen to context closure from CloseRead.

ctx := conn.CloseRead(context.Background())
<-ctx.Done() // Closed.

(You should always either call Read manually or use CloseRead, whichever suits your use-case.)

[matheuscscp]

In my case, the server goroutine is the one talking first, so it sends a wsjson.Write() to the client, then immediately calls wsjson.Read() to read the client response. In this case, the client (who initiated the websocket connection) is the real "server". So I have 3 events that must happen in my select:

• case <-ctx.Done(): Here, the server is supposed to finish the session and close the websocket connection with the client, and the goroutine must return.
• case req <-reqsChannel: There's a new request to be processed. The server will wsjson.Write() then wsjson.Read().
• case <-connClosed: Here, the client itself closed the websocket connection. The goroutine must return.

This is what I wanna do in a nutshell.

[matheuscscp]

This select is running on an infinite for { loop inside the goroutine.

[matheuscscp]

Here's exactly what I'm doing:

https://github.com/matheuscscp/serve-for-me/blob/845f0866cdd5562ed6cf2115487dbb1404d14c0a/server.go#L154-L165

If you have time you can clone this repo and reproduce my issue, if you remove the ping+pong in these lines and run the test, you'll see a test case failing, and the reason why it fails is because my server is stuck on this goroutine. It must return for the test to pass (returning will cause a defer to remove the *backend from the list).

[mafredri]

It does indeed seem like you could utilize CloseRead on the server rather than the write/read cycle.

[matheuscscp]

It does indeed seem like you could utilize CloseRead on the server rather than the write/read cycle.

Cool, I'll try and report back!

[matheuscscp]

I'm not sure I understand CloseRead. Looks like it starts a goroutine to read and discard all the bytes from the connection?? I don't want to discard

[matheuscscp]

CloseRead did not help me at the end, as it seems to be designed for discarding the data from the connection, and that's not my goal.

I instead read the code of wsjson.Read() and found out about websocket.(*Conn).Reader(). Using this method I was able to achieve what I wanted, a stream of messages whose end can be detected with a channel:

https://github.com/matheuscscp/serve-for-me/blob/b50de347f9df1e455083eef6f5365fc063a8e472/internal/reader/reader.go#L21-L27

This method of reading may be useful to others, please let me know if the project has interest on a contribution. My implementation uses generics to make the returned channel be capable of returning any type, but it still assumes JSON transport. It could be added as-is to the wsjson package, or could instead be added to the main package if the channel had the type <-chan io.Reader.

[mafredri]

I'm glad your problem is solved @matheuscscp 👍🏻. Thanks for the contribution offer but I think the use-case of using reading JSON and using channels to return the data is a bit too specific for this library. Utilizing generics is a modernization that's not off the table though.

Closing as the problem is solved.