Do not handle network error in SetCloseHandler()

[nak3]

The 666c197 added an error handling in SetCloseHandler() and peer stops getting CloseError when network issue like write: broken pipe happens because the close handle returns the error.

Hence this patch changes to skip network error handling.

[nak3]

For more detail, we have an unit test as https://github.com/knative/serving/blob/65ce2aece44a5bc5550b54aef657a82f0a6ce61b/pkg/autoscaler/statserver/server_test.go#L111 but it stops getting CloseError on websocket v1.5.1.

[coreydaley]

This may have been fixed in #865 can you take a look and verify?

[nak3]

No, #865 does not fix the issue. I looked at and also verified it.

[coreydaley]

Then there is a merge conflict with this pull request now that needs to be resolved then.

[ghost]

With this change and 865, the close handler will in effect ignore all errors. Consider changing the code to ignore all errors as as the code did prior to August of this year.

It's more important to return the CloseError to the application than any error returned from writing the control message.

[nak3]

With this change and 865, the close handler will in effect ignore all errors.

I think the close handler with this PR will not ignore all errors but will return some error such as errInvalidControlFrame and errWriteTimeout.

Consider changing the code to ignore all errors as as the code did prior to August of this year.
It's more important to return the CloseError to the application than any error returned from writing the control message.

I sort of agree that the close handle should ignore all errors. But I cannot confirm that so this PR ignores network error only for now.

[ghost]

• errWriteTimeout implements the net.Error interface and is therefore ignored by this PR.
• WriteControl(CloseMessage, FormatCloseMessage(code, ""), t) will not return errInvalidControlFrame. We know that CloseMessage is a valid control frame type and that FormatCloseMessage(code, "") is a valid control frame payload.

The websocket connection ignored the error returned from echoing the close message until the PR in August. It seems safe to revert back to the original code.

[nak3]

Okay, thank you. Updated

[nak3]

@coreydaley Could you please take a look?

[nak3]

@coreydaley gentle ping.

[AlexVulaj]

There was a recent issue brought up about noisy, unactionable error messages that may be related here: #878

I'm in favor of taking a similar approach and ignoring the error in this specific case. @coreydaley thoughts?

[nak3]

@coreydaley @AlexVulaj Sorry for bothering you. But could you please take a look?

[nak3]

@coreydaley @AlexVulaj gentle ping.

[dprotaso]

Hey folks - what's the latest with this PR? Knative is hoping to bump to 1.5.1+ but this is blocking us

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (871f6bb) 70.52% compared to head (42fd2c0) 71.21%.
Report is 3 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #863      +/-   ##
==========================================
+ Coverage   70.52%   71.21%   +0.69%     
==========================================
  Files          11       11              
  Lines        1591     1584       -7     
==========================================
+ Hits         1122     1128       +6     
+ Misses        358      349       -9     
+ Partials      111      107       -4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[AlexVulaj]

@nak3 @dprotaso hey, sorry about the delay. Change is merged - thanks for contributing!