-
Notifications
You must be signed in to change notification settings - Fork 136
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
Logging failure after 1.1 #105
Comments
As an aside, and we should fix it here, the logging config in the example in the README still says |
Removing the |
It looks to me from the logrus docs that when we're importing logrus via |
Nope! Turns out I was totally off-base there. It's our default logger that breaks everything. Works fine if we pass |
I have a minimal failing test case that exercises the broken code: func TestDefaultFormatter(t *testing.T) {
formatter := &DefaultLogFormatter{}
b, err := formatter.Format(log.WithFields(
log.Fields{
"level": "info",
"msg": "something",
},
))
fmt.Printf("%v\n", err)
fmt.Println(string(b))
} This test panics(!) because it reaches log.Panicln, which we shouldn't be hitting at all! I'm still working thru this but will pick it up tomorrow morning. @justenwalker any thoughts on this? |
I think the problem is here Essentially, PanicLevel == 0, so any log entry with an un-initialized level is assumed to be Panic |
logrus automatically handle os.Exit and panic when using the appropriate log levels, so it is unecessary to do so in the formatter Fixes TritonDataCenter#105
Logrus automatically handle os.Exit and panic when using the appropriate log levels, so it is unnecessary to do so in the formatter Fixes TritonDataCenter#105
The real issue is handling Panic and Fatal in the Formatter - it just doesn't make sense and it is also redundant since Logrus does this for us. #106 should fix the bug (and update the README for the "go" format) |
Thanks for the assist, @justenwalker! |
I've verified that this fix corrects the problem described at the top of the issue as well. |
Will release this in 1.2.0 (master has a new config flag from #102) this morning. |
Given the following config file:
we expect the output to be:
but instead we get:
This failure happens after the logging framework is set up in this section. But if we force the failure to happen before we set up the logging, for example with the config file, we get the same non-logging behavior:
The text was updated successfully, but these errors were encountered: