status: support wrapped errors in FromContextError #4977
Merged
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
Return an appropriate Status from status.FromContext error if either the supplied error or an error in its chain is one of the context sentinel error values.
|
|
|
Is there a reason this was created as a draft PR? Please agree to the CLA or we cannot take this PR. Otherwise this looks good to me. There is a chance we need to re-add support for Go1.11 in the future, but if we do that we can have a 1.11 implementation of this function that does not use |
|
Thank you for the quick feedback. I created the PR as a draft:
|
easwars
added
Type: Behavior Change
easwars
approved these changes
Nov 19, 2021
dfawley
approved these changes
Nov 19, 2021
dfawley
changed the title
andreimatei
added a commit
to andreimatei/grpc-go-1
that referenced
this pull request
Jan 7, 2022
pickerWrapper had logic very similar to status.FromContextError() for transforming Context errors to status errors. This patch removes the duplication by delegating to the status library. Besides removing the code duplication, the status library is arguably more robust because it doesn't rely on ctx.Error() to only ever return two types of errors. I believe this patch and the previous one stand on their own, but, FWIW, they're also motivating by me wanting to experiment in the CockroachDB codebase with using a custom implementation of context.Context whose Err() method can return better errors than the stdlib context.Context. These errors would still wrap context.Canceled. Such an implementation would technically break the documentation of context.Context, which seems to exhaustively list the sentinel error that context.Context can return. Still, as grpc#4977 showed, most code should support wrapped context errors. This patch moves from "most code" to "all code" in gRPC. I haven't checked which of the callsites I've touched use contexts that might be inherited from a gRPC client, as opposed to contexts derived inside gRPC from context.Background (which contexts would not be affected by whatever I do outside of gRPC), but unifying all the context error handling code seems like a good idea to me universally.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Return an appropriate Status from status.FromContext error if either the supplied error or an error in its chain is one of the context sentinel error values.
Closes #4976
RELEASE NOTES: