-
Notifications
You must be signed in to change notification settings - Fork 475
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
gRPC server supports PanicHandler
#319
base: main
Are you sure you want to change the base?
Conversation
Supports `PanicHandler` for the gRPC server to allow users to catch and log the panic at the client side. Currently, when the plugin panics, the panic is captured only by the stderr rpc channel, which is then logged by the client side with "DEBUG" log level. In most cases, the panic information should be of the "ERROR" log level by the definition of log level. This `PanicHandler` can help with that. In some other cases, this hook allows users to do other handling when the provider crashes.
@@ -73,6 +78,21 @@ func (s *GRPCServer) Init() error { | |||
if s.TLS != nil { | |||
opts = append(opts, grpc.Creds(credentials.NewTLS(s.TLS))) | |||
} | |||
|
|||
if s.PanicHandler != nil { |
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.
It seems to me like the go-grpc-middleware recovery interceptor still provides the ability to return these panics as errors even if you don't want to provide a recovery handler function, so this nil check may not be necessary if I am understanding this correctly: https://github.com/grpc-ecosystem/go-grpc-middleware/blob/main/interceptors/recovery/interceptors.go#L52
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.
If we don't do nil check here, and don't provide a PanicHandler
, the behavior changes from panicing (the current behavior), to returning an error. Would this be a breaking change?
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 for adding the panic handler. Can you add some test cases for the same ?
Also, there is another PR -#292 which aims to handle the scenario but this change seems like a better way of handling
Supports
PanicHandler
for the gRPC server to allow users to handle the panic at the plugin side instead of directly down.Currently, when the plugin panics, the panic is captured only by the stderr rpc channel, which is then logged by the client side with "DEBUG" log level. In most cases, the panic information should be of the "ERROR" log level by the definition of log level. This
PanicHandler
can help with that. In some other cases, this hook allows users to do other handling when the provider crashes.