[BUG] 1.5.1: use of closed network connection, 1.5.0 is fine

[bmhatfield]

Is there an existing issue for this?

• 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:

• use of closed network connection #48
• Error: "write tcp use of closed network connection" #439

However both these issues predate 1.5.0 and 1.5.1 by some margin.

[simon28082]

I've had the same problem recently, I'll try to roll back to 1.5.0

[simon28082]

My own problem, solved.

[Hayden-Chang]

My own problem, solved.

Hi simon, could you describle how did you trigger this error and how did you resolved it?

[StevenACoffman]

@simon28082 I'm curious if you can summarize what caused and solved your problem, as I'm experiencing the same symptoms.

[Enviy]

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.

[jaitaiwan]

That's very weird. Thanks for the feedback.

[StevenACoffman]

@Enviy This issue is resolved by #894 so if the 1.5.1 commit includes this, it works, but otherwise you will still have the issue.

[StevenACoffman]

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.

[Enviy]

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 1bddf2e 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.

[StevenACoffman]

@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.

[jaitaiwan]

v1.5.3 has been released which includes 894 so I'm closing this one out. Thanks folks