fix: Add atomic.Bool to ensure wsConnection.Disconnect() is only called once #359
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #359 +/- ##
==========================================
+ Coverage 78.46% 78.86% +0.40%
==========================================
Files 25 25
Lines 2419 2423 +4
==========================================
+ Hits 1898 1911 +13
+ Misses 413 406 -7
+ Partials 108 106 -2 ☔ View full report in Codecov by Sentry. |
| @@ -19,6 +20,7 @@ type wsConnection struct { | |||
| // For more: https://pkg.go.dev/github.com/gorilla/websocket#hdr-Concurrency | |||
| connMutex *sync.Mutex | |||
| wsConn *websocket.Conn | |||
| closed *atomic.Bool | |||
There was a problem hiding this comment.
Does this need to be a pointer? Seems to be like unnecessary extra allocation.
| if c.closed.Load() { | ||
| return nil | ||
| } | ||
| c.closed.Store(true) |
There was a problem hiding this comment.
To ensure this happens once, I think the correct way is to use the atomic CompareAndSwap instead of separate Load/Store which can race.
| assert.True(t, atomic.LoadInt32(&connectionCloseCalled) == 0) | ||
|
|
||
| // Close connection from server side | ||
| mutex.Lock() |
There was a problem hiding this comment.
What does this mutex protect against? Does serverConn value ever change (except from nil to the only connection we get)? Can serverConn be nil here?
| require.Equal(t, 1, len(logger.logs)) | ||
| require.Contains(t, logger.logs[0], "Errorf: Cannot read a message from WebSocket: read tcp") | ||
| require.Contains(t, logger.logs[0], "use of closed network connection") |
There was a problem hiding this comment.
Do we care about the log messages produced? It looks fragile to make the tests dependent on the exact formatting of the messages.
Addresses this issue by addding an atomic.Bool so we only close the underlying websocket connection once. This PR also adds the test
TestDisconnectServerWSConnectionto ensure that that error log isn't generated when the connection is closed server-side. I renamedTestDisconnectWSConnectiontoTestDisconnectClientWSConnectionsince it tests closing the connection from the client-side, though the comments in the test implied it tested disconnecting from the server.Perhaps it would be better to simply ignore the error when we close the connection twice? I'm unsure if there are error conditions where we'd want to be able to try to close the connection again.