kratos
kratos copied to clipboard
errors had been ignore or covered when too much err happend
What happened:
when too much err happened ,error info has been ignored. 由于err变量是同一个,后续的err会把之前执行过程中的error信息覆盖掉,导致错误信息被掩盖。 而且由于是FIFO的方式执行hook function;后续执行过程中不管有没有发生err,都会覆盖掉此前出现的err。
What you expected to happen:
avoid error info being ignore when too much err happened . 如果出现大量的err,在对变量重复赋值之前打印出err信息,将此前执行过程中的err暴露出来。
How to reproduce it (as minimally and precisely as possible):
for _, fn := range a.opts.afterStop {
if err != nil {
log.Warnf("%s", err)
}
fnErr := fn(sctx)
if fnErr != nil {
err = fnErr
}
}
for _, fn := range a.opts.beforeStop {
if err != nil {
log.Warnf("%s", err)
}
fnErr := fn(sctx)
if fnErr != nil {
err = fnErr
}
}
Anything else we need to know?:
Environment:
- Kratos version (use
kratos -v
):lastest - Go version (use
go version
):1.21.5 - OS (e.g:
cat /etc/os-release
): - Others:
🤖
Hello @SchopenhauerZhang! :wave:
I'm Dosu, a friendly bot here to lend a helping hand with issues, questions, and contributions around the Kratos repository. While we're waiting for a human maintainer to review your issue, I'm here to help keep things moving. Looking forward to assisting you further!
To prevent error information from being ignored or overwritten when multiple errors occur in the Kratos Go microservices framework, you can use the multierror package. This package allows you to collect multiple errors and handle them all at once.
In the provided context, you can modify the unaryClientInterceptor and streamClientInterceptor functions to use multierror. Here's how you can do it:
import (
"github.com/hashicorp/go-multierror"
)
func unaryClientInterceptor(ms []middleware.Middleware, timeout time.Duration, filters []selector.NodeFilter) grpc.UnaryClientInterceptor {
return func(ctx context.Context, method string, req, reply interface{}, cc *grpc.ClientConn, invoker grpc.UnaryInvoker, opts ...grpc.CallOption) error {
// ...
var result *multierror.Error
_, err := h(ctx, req)
if err != nil {
result = multierror.Append(result, err)
}
return result.ErrorOrNil()
}
}
func streamClientInterceptor(filters []selector.NodeFilter) grpc.StreamClientInterceptor {
return func(ctx context.Context, desc *grpc.StreamDesc, cc *grpc.ClientConn, method string, streamer grpc.Streamer, opts ...grpc.CallOption) (grpc.ClientStream, error) {
// ...
var result *multierror.Error
stream, err := streamer(ctx, desc, cc, method, opts...)
if err != nil {
result = multierror.Append(result, err)
}
return stream, result.ErrorOrNil()
}
}
In this code, we're using the Append function from the multierror package to collect all errors. The ErrorOrNil function is then used to return nil if there are no errors, or the errors themselves if there are any. This way, no error information will be ignored or overwritten.
The error handling mechanism in the Kratos Go microservices framework is primarily handled by the unaryClientInterceptor
and streamClientInterceptor
functions.
In the unaryClientInterceptor
function, the error handling is done by the invoker
function which is called inside the handler function h
. The invoker
function takes in the context, method, request, reply, client connection, and options as parameters and returns an error. If an error occurs during the invocation of the RPC, it will be returned by the invoker
function and subsequently by the unaryClientInterceptor
function.
h := func(ctx context.Context, req interface{}) (interface{}, error) {
// ...
return reply, invoker(ctx, method, req, reply, cc, opts...)
}
_, err := h(ctx, req)
return err
In the streamClientInterceptor
function, the error handling is done by the streamer
function. The streamer
function takes in the context, stream descriptor, client connection, method, and options as parameters and returns a client stream and an error. If an error occurs during the creation of the stream, it will be returned by the streamer
function and subsequently by the streamClientInterceptor
function.
return streamer(ctx, desc, cc, method, opts...)
These functions are used as interceptors for unary and streaming RPCs respectively. They allow for the interception of the RPC call, providing an opportunity to handle errors that may occur during the call.
Please let me know if you need further clarification or assistance.
Sources
This response is meant to be useful and save you time. It is not meant to be a precise solution, but rather a starting point for your own research.
Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.
If you want to continue the conversation, start your reply with @dosu-bot.