-
Notifications
You must be signed in to change notification settings - Fork 476
Print panic output on Error log level #292
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
Conversation
@tomhjp Would you mind giving this PR a review? |
Anything I can help with to get a review going? |
@VioletHynes Would your team have some bandwidth to review this one? |
Hi there -- this isn't my team's area but I'll try and forward this to the team that owns this. Thanks :) |
Thanks, appreciate it! |
Co-authored-by: Robert <17119716+robmonte@users.noreply.github.com>
@robmonte Gentle reminder to review the PR 😄 |
@robmonte Just wanted to check the process on the PR. Is there anything I can do to speed up the process? |
@hanzei Sorry for the delay since my last comment. At first a concern with this change was that, as you said, it's a little hacky to be based on string prefixes. An alternate solution pull request was opened that you can see here: #319 Providing a PanicHandler might be a "more correct" solution long term and so we were looking into that a bit, however given the widespread use of go-plugin it definitely makes us more cautious with changes. I'm not familiar enough with gRPC as a whole to give that PR a proper review despite it seeming straightforward. However since the entire log level checker is already based on that same string logic, we think it makes sense to go ahead with this smaller, simpler change for now. |
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.
Approving the PR after reviewing the changes.
Awesome, thanks for merging the PR! Looking forward to the next release 🚀 |
First of all, thanks for creating this awesome library! We at Mattermost use it a lot.
If a plugin panics, the panic message goes to stderr of the plugin. Because the log lines don't have any levelled prefix like
[ERROR]
, the panic message would end up in the Debug level. That makes it hard to spot, why a plugin panicked.The (hacky) solution is to check if any unparsed lines start with
panic:
. If that is the case, this line and all unparsed following lines go to the Error level. Most likely, these will be the last log lines anyway before the process dies.I tried adding a test to cover, but that would require spinning up another process (that then panics) to cover this PR.