Context expiration on `Read` shuts down WebSocket

[misberner]

If the context I pass to (*Conn).Read expires, this shuts down the entire websocket. conn_notjs:160 is at fault here.

This is confusing and severely constraints the ways in which this library can be used. For example, the following is not possible:

for {
  readCtx, cancel := context.WithTimeout(readCtx, 10 * time.Second)
  mt, msg, err := conn.Read(readCtx)
  cancel()
  if err == context.DeadlineExceeded {
    fmt.Println("No message so far. Don't worry, connection is still alive, let's wait another 10s.")
    continue
  }
}

It is also extremely un-idiomatic since contexts communicate expectations/bounds by the caller only, and the effects of their expiration should be local to the call.

The only way to work around this would be to move all reads in a goroutine and communicate the messages read back via a channel, which is.. meh.

[nhooyr]

100% agree this is unfortunate and definitely not a design decision but the API exposed to us by *http.Client is a io.ReadWriteCloser. The only way we can block an in progress Read or Write is by closing the connection. Later on when http2 support is in, this limitation will likely still exist both server and client side. See #4 and the associated Go issues for details.

It is also extremely un-idiomatic since contexts communicate expectations/bounds by the caller only, and the effects of their expiration should be local to the call.

I agree but there isn't a good way yet to bound a context to a IO operation so unfortunately this is the best that can be done.

The only way to work around this would be to move all reads in a goroutine and communicate the messages read back via a channel, which is.. meh.

Yes, it's unfortunate but that is your best shot at the moment, shouldn't be much boilerplate. In my experience such patterns are uncommon compared to just closing the connection if there hasn't been a message sent in X amount of time. If you really need that, I'd go with gorilla/websocket or gobwas/ws, I know gobwas/ws is particularly optimized for this.

I'll document the decisions here better for future users.