fix(internal/retry): never return nil from GRPCStatus() #8128
+28
−1
Conversation
This file contains 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
|
🤖 I detect that the PR title and the commit message differ and there's only one commit. To use the PR title for the commit history, you can use Github's automerge feature with squashing, or use -- conventional-commit-lint bot |
An error's GRPCStatus() method should never returns nil, which maps to a status with Code.OK (https://github.com/grpc/grpc-go/blob/642dd63a85275a96d172f446911fd04111e2c74c/internal/status/status.go#L71-L76). Instead it should return an actual error code, such as Status.Unknown. This addresses googleapis#8127.
noahdietz
reviewed
Jun 16, 2023
|
@atollena sorry out of habit I caught up your branch 😬 might want to pull before pushing a new commit |
noahdietz
changed the title
|
I believe this should be fine. This is used by a handful of our manual clients. |
noahdietz
approved these changes
Jun 16, 2023
|
Thanks @codyoss ! I've updated the PR in place. Setting |
noahdietz
added
the
automerge
tritone
approved these changes
Jun 17, 2023
kokoro-team
removed
the
kokoro:run
gcf-merge-on-green
bot
removed
the
automerge
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).
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
An error's GRPCStatus() method should never returns nil, which maps to a status with Code.OK (https://github.com/grpc/grpc-go/blob/642dd63a85275a96d172f446911fd04111e2c74c/internal/status/status.go#L71-L76). Instead it should return an actual error code, such as Status.Unknown.
This addresses #8127.