fix(internal/retry): Simplify gRPC status code mapping of retry error #8196
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
|
Thanks to @dfawley for suggesting this here: grpc/grpc-go#6374 (comment) |
atollena
force-pushed
the
antoine/simplify-retry-error
branch
from
800df30 to
017c367
Compare
|
🤖 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 |
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
force-pushed
the
antoine/simplify-retry-error
branch
from
017c367 to
6a7ac3a
Compare
atollena
changed the title
|
@noahdietz nope seems fine to me as well. Error strings are undefined behavior in my eyes -- at least for this instance. |
noahdietz
approved these changes
Jul 5, 2023
|
@atollena I'm updating your branch and will get it merged. I'll wait until the continuous integration tests pass upon merging to cut a release, but will ping you on the release when it happens. |
noahdietz
added
the
automerge: exact
noahdietz
approved these changes
Jul 5, 2023
noahdietz
approved these changes
Jul 5, 2023
noahdietz
added
the
kokoro:force-run
kokoro-team
removed
the
kokoro:force-run
gcf-merge-on-green
bot
removed
the
automerge: exact
|
Thank you for merging. |
gcf-merge-on-green bot
pushed a commit
that referenced
this pull request
Jul 6, 2023
🤖 I have created a release *beep* *boop* --- ## [0.110.4](https://togithub.com/googleapis/google-cloud-go/compare/v0.110.3...v0.110.4) (2023-07-05) ### Bug Fixes * **internal/retry:** Simplify gRPC status code mapping of retry error ([#8196](https://togithub.com/googleapis/google-cloud-go/issues/8196)) ([e8b224a](https://togithub.com/googleapis/google-cloud-go/commit/e8b224a3bcb0ca9430990ef6ae8ddb7b60f5225d)) --- This PR was generated with [Release Please](https://togithub.com/googleapis/release-please). See [documentation](https://togithub.com/googleapis/release-please#release-please).
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.
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 obvious why this can't result in infinite recursion.
A previous change I made to this code made sure this method never returns Status.OK (#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
GRPCStatusand 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).