-
-
Notifications
You must be signed in to change notification settings - Fork 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
gateway: degrade error in gateway to log to reduce noise #2971
Conversation
1391440
to
c1f7428
Compare
@@ -506,7 +506,7 @@ func webError(w http.ResponseWriter, message string, err error, defaultCode int) | |||
|
|||
func webErrorWithCode(w http.ResponseWriter, message string, err error, code int) { | |||
w.WriteHeader(code) | |||
log.Errorf("%s: %s", message, err) // TODO(cryptix): log errors until we have a better way to expose these (counter metrics maybe) | |||
log.Infof("%s: %s", message, err) // TODO(cryptix): log until we have a better way to expose these (counter metrics maybe) |
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.
Can we split out this TODO into an issue?
I think this is probably insufficient. Some of these are legitimate errors, some are just totally normal from the gateway's perspective. Error handling in the gateway generally needs to be reworked. |
But 👍 LGTM, since it reduces log noise. |
It does and that is what #2972 is for. |
I agree with @lgierth here, i dont think this is what we want to do. We should filter out explictly which errors we want to demote, this was here for a reason, we want to know when something has gone wrong and handle it accordingly. |
c1f7428
to
919d835
Compare
Reworked it. |
@@ -158,6 +159,11 @@ func (i *gatewayHandler) getOrHeadHandler(w http.ResponseWriter, r *http.Request | |||
w.WriteHeader(http.StatusServiceUnavailable) | |||
fmt.Fprint(w, "Could not resolve path. Node is in offline mode.") | |||
return | |||
} else if err == namesys.ErrResolveFailed { |
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.
lets change this over to an error switch
We might also want to handle context deadline exceeded errors (i see these somewhat often too) and add some tests. |
+1 to being very explicit about what's getting demoted and making
|
919d835
to
51e55d7
Compare
Updated. |
case nil: | ||
// core.Resolve worked | ||
case core.ErrNoNamesys: | ||
if !i.node.OnlineMode() { |
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 happens if we get ErrNoNamesys and we're 'online' ? Even if this can never happen we should still check that case here and log an error
20d4bf5
to
bba2a85
Compare
Updated |
bba2a85
to
9124d2e
Compare
@lgierth can you CR on this? |
LGTM, just waiting on a 👍 from @lgierth |
// core.Resolve worked | ||
case namesys.ErrResolveFailed: | ||
// Don't log that error as it is just noise | ||
w.WriteHeader(http.StatusBadRequest) |
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.
400 doesn't fit here since the 4xx range is for client errors, where the client can amend the request to possibly get a successful response. 502 Bad Gateway or, (less specific) 500 Internal Server Error would be sufficient.
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.
ErrResolveFailed means that the link passed by client can't be resolved, this doesn't mean it is server fault that it can't be resolved.
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.
Poor server, we're blaming everything on it :P The meaning of a 4xx for the client is "don't retry unless you make changes to the request" though, and the reason for ErrResolveFailed can be an invalid /ipns string, or a failure in DNS resolution.
Anyhow, I don't have strong feelings about it right now, because the 400 status here doesn't regress from what we already have. We obviously need more granular errors through the stack though.
} | ||
fallthrough | ||
default: | ||
// all other erros | ||
webError(w, "Path Resolve error", err, http.StatusBadRequest) |
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 okay to leave this existing line with 400 for now, but the same applies here.
@lgierth updated |
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.
Thanks LGTM 👍
Wait, it broke the tests... |
@lgierth can you confirm change in behaviour here:
|
It logs all errors including expired IPNS keys and other non important errors. License: MIT Signed-off-by: Jakub Sztandera <kubuxu@protonmail.ch>
License: MIT Signed-off-by: Jakub Sztandera <kubuxu@protonmail.ch>
1ad08da
to
63ea995
Compare
License: MIT Signed-off-by: Jakub Sztandera <kubuxu@protonmail.ch>
63ea995
to
ce96b91
Compare
This LGTM 👍, I went and resolved the conflicts with the recent coreapi changes, @Kubuxu I thought that's likely okay :) Sorry for sitting on it so long! |
It logs all errors including expired IPNS keys and other non important
errors.
License: MIT
Signed-off-by: Jakub Sztandera kubuxu@protonmail.ch