websocket
websocket copied to clipboard
gorilla
[BUG] 1.5.1: use of closed network connection, 1.5.0 is fine
Is there an existing issue for this?
- [X] I have searched the existing issues
Current Behavior
After upgrading from websocket 1.5.0 to 1.5.1, my service started regularly erroring with read tcp 10.40.0.207:8080->10.40.0.1:37429: use of closed network connection. Reverting back to 1.5.0 from 1.5.1 quieted these errors.
Expected Behavior
I expected 1.5.0 -> 1.5.1 to be a seamless upgrade, continuing to not error about use of closed network connection.
Steps To Reproduce
This may be hard to reproduce, as I am unsure if this was just unmasked in our code or if a new issue was introduced to gorilla/websocket in 1.5.1. I will update this issue if I am able to find a clean reproduce case. We have quite a bit of supporting code so the bug here could be entirely in our stack, not in gorilla/websocket.
However, a direct upgrade and then revert with no other corresponding changes which results in errors and then those errors going away seems like a good threshold to at least start a conversation.
Anything else?
I reviewed the existing issues and found:
- https://github.com/gorilla/websocket/issues/48
- https://github.com/gorilla/websocket/issues/439
However both these issues predate 1.5.0 and 1.5.1 by some margin.
My own problem, solved.
Hi simon, could you describle how did you trigger this error and how did you resolved it?
@simon28082 I'm curious if you can summarize what caused and solved your problem, as I'm experiencing the same symptoms.
I was also encountering this issue. Despite checking for the net.ErrClosed error with errors.Is(), it was not being correctly caught.
As strange as it sounds, it was resolved by calling go get github.com/gorilla/websocket@latest. This was strange because the package version in go.mod did not change (version 1.5.1). A real riddle me this scenario.
@Enviy This issue is resolved by https://github.com/gorilla/websocket/pull/894 so if the 1.5.1 commit includes this, it works, but otherwise you will still have the issue.
I believe we need to wait unitl 1.5.2 to safely use Gorilla without this issue, unless you are ok with pinning to the specific commit where it is resolved.
Hey @StevenACoffman, thanks for the response! It doesn't look like #894 is included in 1.5.1 so I've pinned github.com/gorilla/websocket to the commit 1bddf2e0dba6f35492b0f5614905b291cd0ab88d in go.mod for now (just because it's the most recent commit). Do you know how often the patch version is incremented? I was surprised it wasn't incremented for each bug fix.
@Enviy gorilla/websockets was unmaintained for a long period after the v1.5.0 release, and then some volunteers stepped forward together and tried to resurrect this project. When the new maintainer(s) cut the v1.5.1 release, that release had a lot of bugs. Since then, some fixes have been merged. Stepping in to maintain a widely used but messy project is a thankless task.
At this point, there's no established cadence for releases.