-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix error codes for http2, x509 and tls errors #2025
Conversation
e802dff
to
bcf6fb9
Compare
Codecov Report
@@ Coverage Diff @@
## master #2025 +/- ##
==========================================
- Coverage 71.73% 71.72% -0.02%
==========================================
Files 179 179
Lines 14086 14095 +9
==========================================
+ Hits 10105 10109 +4
- Misses 3345 3347 +2
- Partials 636 639 +3
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
25c0d3a
to
9972481
Compare
9972481
to
a3866d4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm concerned that we're replicating a scenario in tests that matches our expectations but doesn't reproduce what happens in production. Could we add integration tests for this to ensure it's fixed?
require.Error(t, err) | ||
|
||
code, msg := errorCodeForError(err) | ||
assert.Equal(t, unknownHTTP2StreamErrorCode+errCode(http2.ErrCodeInternal)+1, code) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This summing of error codes seems very brittle, and I just saw we do the same in http2ErrorCodeOffset()
. :-/ Why is this done instead of having a specific error code we can assert on?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there are a bunch of error codes defined in the http2 specification and some of them can be returned for stream, some for connection errors so it was easier to just have 20 codes between those and make the codes on the spot instead of defining like 14 error codes per http2*Error
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, I guess it's fine since they're constants, but it's very confusing to read. Maybe some comments would help.
a3866d4
to
75a839d
Compare
By integration tests do you mean using the js We can move them (or add additional) tests in |
a7d0837
to
22023f4
Compare
lib/netext/httpext/error_codes.go
Outdated
return x509HostnameErrorCode, x509HostnameErrorCodeMsg | ||
case *tls.RecordHeaderError: | ||
case tls.RecordHeaderError: | ||
return defaultTLSErrorCode, err.Error() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do think we should probably add TLSHeaderErrorCode ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Given that defaultTLSErrorCode
doesn't seem to be used for anything else, I am not sure it's necessary 🤷♂️
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
well this is also the only tls error I am matching ... as it is the only one I get, but arguably it isn't the only one that can be so it taking the "default" one seems like a bad idea ... ;)
68ff9c7
to
398b6f7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, nice work on the tests! 👏
for _, opt := range opts { | ||
switch opt.Key { | ||
case NullOpt: | ||
t.Fatalf("unsupported multibin option %d, the NullOpt should not be used", opt.Key) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What's the purpose of defining/checking for it then?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Literally a linter told me I don't check all of them and it is nice to have a more specific message for why it failed. On the other hand, maybe I should add that this will happen also if Key
wasn't set as it will default to 0 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, but I mean why even define NullOpt
at all then? It's not used anywhere, and you could start ConnContextFuncOpt
at iota + 1
if you don't want to use 0
. Though it's a minor thing, I don't mind it much, just wondering.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
hm .... I guess given that this is not user-facing code it might be easier if I just drop it 🤔 in general I prefer to have it for user-facing enums so we can see when it isn't set and provide an error.
3d34f68
to
f1881ec
Compare
2a51fc7
to
202f0e7
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think the whole MultiBinOptWrap
is necessary. If you need custom low-level options in a certain test, simply spin up a custom httptest.NewUnstartedServer()
, it's only a few lines of code. If you need it in multiple tests, write another small helper around it, instead of making HTTPMultiBin
into more of a monster than it already is... We risk it becoming sentient and eating us soon 😅
202f0e7
to
df1929f
Compare
I am fine by this ... but in that case I don't think we have more than a few tests that actually use more then what |
I'd still very much prefer a new 20-line helper that allows for the modification of the low-level options than cramming that in We said we want to split |
1e93136
to
d1654fe
Compare
this happens ever 1 out of 3-4 runs :( ... but I don't know with what I could've broken it |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, nice job fixing that test 🎉
It seems http2, x509 and tls errors are not pointer errors, after all. I mostly found this through the fact that even after the last patches it still didn't match them, but now there are finally tests for all of them, so hopefully this will be a permanent fix.
This was dropped as part of #2008 but it will be better if we differentiate between different timeouts Also add test for the `request timeout` error code in `httpext`
e9f2385
to
09862f2
Compare
It seems http2, x509 and tls errors are not pointer errors, after all.
I mostly found this through the fact that even after the last patches it
still didn't match them, but now there are finally tests for all of
them, so hopefully this will be a permanent fix.