-
-
Notifications
You must be signed in to change notification settings - Fork 330
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
Log expected api errors as warning instead of error #5285
Conversation
Performance Report✔️ no performance regression detected Full benchmark results
|
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 am not sure all non-500 error codes are just warnings
regarding this, if there are non-500 error codes which are not considered a warning but something critical then the error code must be changed |
this.logger.error(`Req ${req.id} ${operationId} error`, {}, err); | ||
|
||
if (err instanceof ApiError) { | ||
this.logger.warn(`Req ${req.id} ${operationId} failed`, {reason: err.message}); |
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.
@wemeetagain I want to establish this pattern that for non-critical issues we use the terms "failed" and "reason" instead of "error" as based on my observations the term "error" scares a lot of users, especially less technical ones. What do you think?
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 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 think the stack trace is very useful, but we can move the log to debug
will full trace, an additional warn
log in this format is acceptable
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.
but we can move the log to debug will full trace, an additional warn log in this format is acceptable
that's also what I was considering, sounds like a reasonable compromise. Not sure if it makes sense here though in case of ApiError
, if someone feels strongly about having a stack trace for those we should probably log it as well to debug
🎉 This PR is included in v1.7.0 🎉 |
Motivation
Expected API errors (
ApiError
) should be logged as warnings instead of errors to not unnecessarily scare users. Printing out the stacktrace does not help here either, it just creates noise.Description
Check if error is
ApiError
and just log it aswarn
and only print out theerr.message
.Unexpected errors (non
ApiError
) will still be logged aserror
including the stacktrace.Closes #5265, related discussion