status: FromError: return entire error message text for wrapped errors #6150
Conversation
| // err.Error() text and not just the wrapped status. | ||
| // | ||
| // - If err is nil, a Status is returned with codes.OK and no message. |
There was a problem hiding this comment.
Nit: can we explicitly specify it returns true in these two cases, and not use the fact that this is the if on the else of the third case which returns false
There was a problem hiding this comment.
IMO this is such a common pattern that the extra sentences to document "ok" wouldn't be worth worth the clutter they would create. E.g. this is the documentation of context.Deadline():
// Deadline returns the time when work done on behalf of this context
// should be canceled. Deadline returns ok==false when no deadline is
// set. Successive calls to Deadline return the same results.
|
[I should link the original PR #6031 that added wrapping support from this PR, too.] |
|
@dfawley This would indeed be helpful =) Since the response from the server is formed using this function, in this example the response from the server will be more friendly like this: Instead of like now: The only thing is that some error parsers do not expect such changes For example, now the grpc client in jet brains ide returns the following message: After these changes will be something like this: |
I'm fairly sure error strings are not considered part of the API surface; I know the Go standard libraries have changed their error strings at least once or twice. I think this is a good change - also remember that no released version of gRPC works with wrapped status errors anyway (your PR went in after the latest release), so the only real behavior change is that wrapped status errors now unwrap. |
gRPC v1.55.0 that this project depends on came with a change in semantic for status.FromError such that the gRPC status of wrapped errors is returned. The implementation of GRPCStatus in internal/retry code was doing just that. Removing GRPCStatus entirely makes the code much easier to understand: at the moment, status.FromError calls GRPCStatus which in turns calls status.FromError and it's not immediately obviuos why this can't result in infinite recursion. A previous change I made to this code made sure this method never returns Status.OK (googleapis#8128), but I failed to realize that since this project depends on gRPC 1.55 that already handles wrapped errors in status.FromError, we can simply remove the implementation of `GRPCStatus` and let gRPC status.FromError handle unwrapping. Note that I barely had to change the tests, but there *IS* a slight change in behavior: the message of the wrapping error is included in the gRPC error. I think it's fine, bet let me know if you think otherwise (for the same reasons discussed in grpc/grpc-go#6150).
gRPC v1.55.0 with a change in semantic for status.FromError such that the gRPC status of wrapped errors is returned when defined. The implementation of GRPCStatus in internal/retry code was doing just that. Removing GRPCStatus entirely makes the code much easier to understand: at the moment, status.FromError calls GRPCStatus which in turns calls status.FromError and it's not immediately obvious why this cannot result in infinite recursion. A previous change I made to this code made sure this method never returns status Code.OK (googleapis#8128), but I failed to realize that since this project depends on gRPC 1.55 that already handles wrapped errors in status.FromError, we can simply remove the implementation of `GRPCStatus` and let gRPC status.FromError handle unwrapping. Note that I barely had to change the tests, but there *IS* a slight change in behavior: the message of the wrapping error is included in the gRPC error. I think it's fine, bet let me know if you think otherwise (for the same reasons discussed in grpc/grpc-go#6150).
gRPC v1.55.0 with a change in semantic for status.FromError such that the gRPC status of wrapped errors is returned when defined. The implementation of GRPCStatus in internal/retry code was doing just that. Removing GRPCStatus entirely makes the code much easier to understand: at the moment, status.FromError calls GRPCStatus which in turns calls status.FromError and it's not immediately obvious why this cannot result in infinite recursion. A previous change I made to this code made sure this method never returns status Code.OK (googleapis#8128), but I failed to realize that since this project depends on gRPC 1.55 that already handles wrapped errors in status.FromError, we can simply remove the implementation of `GRPCStatus` and let gRPC status.FromError handle unwrapping. Note that I barely had to change the tests, but there *IS* a slight change in behavior: the message of the wrapping error is included in the gRPC error. I think it's fine, bet let me know if you think otherwise (for the same reasons discussed in grpc/grpc-go#6150).
gRPC v1.55.0 with a change in semantic for status.FromError such that the gRPC status of wrapped errors is returned when defined. The implementation of GRPCStatus in internal/retry code was doing just that. Removing GRPCStatus entirely makes the code much easier to understand: at the moment, status.FromError calls GRPCStatus which in turns calls status.FromError and it's not immediately obvious why this cannot result in infinite recursion. A previous change I made to this code made sure this method never returns status Code.OK (googleapis#8128), but I failed to realize that since this project depends on gRPC 1.55 that already handles wrapped errors in status.FromError, we can simply remove the implementation of `GRPCStatus` and let gRPC status.FromError handle unwrapping. Note that I barely had to change the tests, but there *IS* a slight change in behavior: the message of the wrapping error is included in the gRPC error. I think it's fine, bet let me know if you think otherwise (for the same reasons discussed in grpc/grpc-go#6150).
Many users would prefer to see the entire error message along with the wrapped status's code & details, so that data is not "lost". This change implements that preference.
I'm not convinced this is "correct" or "better", but it may be, and I wanted to discuss.
cc @psyhatter
RELEASE NOTES: