[BUG] 1.5.1 uses log.Printf

[jech]

Is there an existing issue for this?

• I have searched the existing issues

Current Behavior

Commit 666c197 is a huge commit with no useful log message, and I keep finding new issues with it.

One of the issues is that it included a bunch of error handling using log.Printf. gorilla/websocket is a generally useful library, and it should not be making any assumptions about my application's logging infrastructure; using log.Printf for logging is a clear violation of this basic principle.

Please revert commit 666c197.

Expected Behavior

A low-lever library should not be doing logging on behalf of the application.

Steps To Reproduce

No response

Anything else?

No response

[AlexVulaj]

Hey @jech thanks for bringing this up. Reverting the entire commit isn't likely to happen as a lot of those changes were to bring our codebase in line with new linters and such. However, could you take a look and see if this PR addresses your issue? #878

[jech]

I understand that it's difficult to rollback the entire commit, but is is practical to submit a PR to undo actual functionality changes

I believe that the proper way to proceed would be to revert said commit, and then resubmit the useful parts with proper commit messages. If that is not done, then somebody will need to fork the package.

[FZambia]

I am also not updating to Gorilla WebSocket v1.5.1 in https://github.com/centrifugal/centrifuge and https://github.com/centrifugal/centrifugo to not introduce unwanted noise to user's logs. Is there a plan to revert the changes made? I agree with above comments and will prefer forking the package than migrating to it in the current state.

[ReToCode]

+1 on this, we have the same concerns in Knative: knative/serving#14597.

[AlexVulaj]

Hey all - one of our maintainers submitted this PR to hopefully undo the logging that was added causing all of the extra noise. Hoping to get that pushed through soon.

[jech]

@AlexVulaj, the problem is that since 666c197 is so large and undocumented, it is impossible to review.

If you want us to trust gorilla/websocket again, you need to revert 666c197, and then resubmit the useful changes in manageable units with proper commit messages. Leaving the commit in and then playing whack-a-mole with the issues it introduced is not going to produce sofftware we can depend on.

[AlexVulaj]

Didn't mean to close this issue - must've been an automated process with the merge of the above PR. I'm leaving this open for discussion until the logging issues are confirmed to be good.