status: FromError: return entire error message text for wrapped errors#6150
Merged
Conversation
zasweq
reviewed
Mar 24, 2023
zasweq
reviewed
Mar 24, 2023
Member
Author
|
[I should link the original PR #6031 that added wrapping support from this PR, too.] |
Contributor
|
@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: |
Member
Author
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. |
atollena
added a commit
to atollena/google-cloud-go
that referenced
this pull request
Jul 3, 2023
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).
atollena
added a commit
to atollena/google-cloud-go
that referenced
this pull request
Jul 3, 2023
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).
atollena
added a commit
to atollena/google-cloud-go
that referenced
this pull request
Jul 3, 2023
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).
atollena
added a commit
to atollena/google-cloud-go
that referenced
this pull request
Jul 3, 2023
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).
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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: