Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

credentials: return Unavailable instead of Internal for per-RPC creds errors #1776

Merged
merged 1 commit into from
Jan 3, 2018

Conversation

jeanbza
Copy link
Member

@jeanbza jeanbza commented Dec 31, 2017

Referencing #1704.

I'm a little confused on the part, "The oauth implementation should return UNAVAILABLE if the oauth server cannot be reached.". Does that mean, all implementers of TokenSource :: Token() (*Token, error) should return UNAVAILABLE if the server cannot be reached? If so I'm happy to try and go through and add them either in this PR or a separate PR.

@jeanbza
Copy link
Member Author

jeanbza commented Jan 1, 2018

I'm rather confused about the failing tests in travis ci; go test ./... -v works locally. Are these flaky tests?

@dfawley
Copy link
Member

dfawley commented Jan 2, 2018

#1693 is about flakes in this test with this error. Here it failed 4/5 times, which is unusual. I restarted all the failing jobs, and we'll see what happens.

@jeanbza
Copy link
Member Author

jeanbza commented Jan 2, 2018

@dfawley 👍 thanks - if it fails again I'll dig and see what I can find

Copy link
Member

@dfawley dfawley left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I restarted all the failing jobs, and we'll see what happens.

Looks like Travis is green now. I guess it was just having a bad day when it ran the first time.

I'm a little confused on the part, "The oauth implementation should return UNAVAILABLE if the oauth server cannot be reached.". Does that mean, all implementers of TokenSource :: Token() (*Token, error) should return UNAVAILABLE if the server cannot be reached? If so I'm happy to try and go through and add them either in this PR or a separate PR.

GetRequestMetadata in the credentials/oauth package should ideally start returning status errors as part of this PR. If we can't distinguish between network errors and other errors, then we may not be able to return the appropriate code without going in and changing the golang.org/x/oauth2 package(s) to enable that. If that's the case, we can return Unauthenticated status errors always for this PR.

@@ -380,7 +380,11 @@ func (t *http2Client) NewStream(ctx context.Context, callHdr *CallHdr) (_ *Strea
for _, c := range t.creds {
data, err := c.GetRequestMetadata(ctx, audience)
if err != nil {
return nil, streamErrorf(codes.Internal, "transport: %v", err)
if _, ok := err.(StreamError); ok {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should be checking whether the error was produced by the status package instead:

if _, ok := status.FromError(err); ok {
  return nil, err
}

It's fine to keep returning streamErrorf(codes.Unauthenticated) below to avoid changing too much at once.

We also should update the comments in credentials/credentials.go for GetRequestMetadata to explain that if a status error is returned, it will be used as the status for the RPC.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@dfawley 👍 done and done; I'll take a closer look at the error structs, apologies for that

@jeanbza
Copy link
Member Author

jeanbza commented Jan 2, 2018

👍 thanks for these comments, I'll work on this tonight

@jeanbza
Copy link
Member Author

jeanbza commented Jan 3, 2018

@dfawley I took a look through some of the golang.org/x/oauth2 implementers (of TokenSource interface), and generally it looks like there's no consistent error statuses being returned. For example:

Certainly nothing like the defined error structs in this library, unless I'm mistaken (which I may be!). Would you prefer me to continue by returning Unauthenticated for now?

@dfawley
Copy link
Member

dfawley commented Jan 3, 2018

it looks like there's no consistent error statuses being returned.

That's what I was afraid of..

Would you prefer me to continue by returning Unauthenticated for now?

Yes, I think that's the best we can do without changes elsewhere - thanks!

@jeanbza
Copy link
Member Author

jeanbza commented Jan 3, 2018

👍 sounds good, give a shout if anything else I can do on this PR

@dfawley
Copy link
Member

dfawley commented Jan 3, 2018

FYI: I filed golang/oauth2#264 as a feature request for oauth2.

@dfawley dfawley changed the title Per issue #1704, return appropriate errors from PerRPCCredential errors credentials: return Unavailable instead of Internal for per-RPC creds errors Jan 3, 2018
@dfawley dfawley merged commit 7aea499 into grpc:master Jan 3, 2018
@menghanl menghanl added this to the 1.10 Release milestone Feb 14, 2018
@menghanl menghanl added Type: Behavior Change Behavior changes not categorized as bugs and removed Type: Bug labels Feb 14, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Jan 18, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Type: Behavior Change Behavior changes not categorized as bugs
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants