websocket clean up resolvers after client abruptly disconnects #1583
Conversation
|
|
||
| c.write(&operationMessage{Type: connectionErrorMsg, Payload: b}) | ||
| c.write(&operationMessage{Type: connectionErrorMsg, Payload: b}) |
There was a problem hiding this comment.
hmm the above change makes this a no-op, right? Is there something missing from this PR?
There was a problem hiding this comment.
Do we need to write same error in loop here?
| c.mu.Lock() | ||
| c.conn.WriteJSON(msg) | ||
| c.mu.Unlock() | ||
| if msg.Type == "data" { |
There was a problem hiding this comment.
this would also ignore keepAlive, connected, and ack messages. I don't think this is what we want
There was a problem hiding this comment.
Yeah @jaredly is right. We cannot afford to miss other types of messages here.
|
@RobertoOrtis can you address Jared's review above? Thanks! |
|
@zdraganov This is another PR that seems to maybe overlap a little with some of the other more recently merged websock PRs. Are you interested in freshening this up and adding a new PR for the remaining valuable bits? |
|
I will take a look. |
|
I think this is more related to this one #1728. I think this can be closed as it's a duplicate. @RobertoOrtis do you think there's something more on top of the mentioned PR? |
|
I appreciate your contribution, but I am closing this as a duplicate. If there's something else I missed, please don't hesitate to open a new PR. |
Describe your PR and link to any relevant issues.
Extends #1248 #1248 (comment)
Websocket resolvers were not being cleaned up after the client abruptly disconnects. For example, when the users close or refresh their browsers. This fixes it by cleaning active resolvers whenever a
sendConnectionErroris called.I have: