Repository navigation
[BUG] websocket on compress close duplicate #859
Description
Is there an existing issue for this?
- I have searched the existing issues
Current Behavior
in this line
Line 138 in ac0789b
and this line
Line 1024 in ac0789b
Expected Behavior
if close duplicate will report this log
2023/10/30 21:56:02 websocket: discarding reader close error: io: read/write on closed pipe
Steps To Reproduce
- create websocket link with "EnableCompression"
- use this websocket write someting
- in server side got log "websocket: discarding reader close error: io: read/write on closed pipe"
Anything else?
2023/10/30 21:56:02 websocket: discarding reader close error: io: read/write on closed pipe
Activity
DVKunion commentedon Jan 25, 2024
the same +1, any solutions or temporary repair suggestions? :)
davidnewhall commentedon Feb 9, 2024
Disabling compression does not get rid of the error. The error seems triggered by keep alives because it happens without any other requests. I sure wish I could pass in a custom logger for this so I can tune the error and figure out which thread it comes from.
jaitaiwan commentedon Feb 10, 2024
What would really help with moving forward with this bug is having reproduction steps. Then we can just run a go debugger and poke at the stacks.
davidnewhall commentedon Feb 10, 2024
Sounds a bit beyond my skill, but I'd be happy to work with someone to figure this out.
I have an app that reproduces this error consistently. I have thousands of users, and I'd like to get this figured out before I release an app update with v1.5.1 of this library (which adds the new log message). If you download the app, you'll also need a (free) account at https://notifiarr.com. There's no (email or anything) verification so you can remain 100% anonymous there.
I'll try to get a reproducible setup using just mulery. Notifiarr users this code for the web socket, and it's much leaner. I'm 100% expecting the "bug" to be in my code, but I really don't know how to find it.
Looks like this error print has been removed. That's interesting and makes me think we're overlooking a bug somewhere.
jaitaiwan commentedon Feb 12, 2024
Thanks for the feedback folks. We recognise that we made a mistake in merging some of these changes and we're working on getting new PRs written and reviewed to fix this going forward.
DVKunion commentedon Feb 18, 2024
Yes, this is just a temporary solution. I have abandoned comrpress to ensure that my logs have no erroneous outputs.If there is a better fix method, please remind me :)
elepedus commentedon May 2, 2024
Did anyone manage to resolve this issue? We're using the library to proxy websocket connections, and would love a fix 🙏
jaitaiwan commentedon May 2, 2024
We’ve done a revert and plan to do a temporary release to cover things I believe .
elepedus commentedon May 2, 2024
Oh awesome! When do you expect to release the fixed version?
jaitaiwan commentedon May 2, 2024
We’re talking about internally how to version it, once the decision is made we’ll do it straight away. In the meantime master represents that future version.
elepedus commentedon May 3, 2024
Thank you! 🙏
conbanwa commentedon Jul 25, 2024
same issue on @1.5.1, and is was just ok on @1.5.0 version
jaitaiwan commentedon Sep 2, 2024
I believe so - v1.5.3 should be safe now.
Make compression reader/writer Close() idempotent
fix(compression): make flate reader/writer Close idempotent