Skip to content
This repository was archived by the owner on Feb 16, 2022. It is now read-only.

Unexpected 'context canceled' errors from multiple usages of the management struct #251

Closed
dev-admin-gridline opened this issue Nov 19, 2021 · 1 comment

Comments

@dev-admin-gridline
Copy link

Description

we are seeing indeterminate behavior from the management.Management struct when attempting to call the auth0 management api in the form of 'context canceled' error messages.

our creation of the management struct is:

func NewManagement(config config.Auth0Config) (*management.Management, error) {
	m, err := management.New(
		config.ManagementAPIDomain,
		management.WithClientCredentials(config.ClientID, config.ClientSecret),
		management.WithClient(http.GridlineDefaultHTTPClient),
	)
	if err != nil {
		return nil, err
	}

	return m, nil
}

you can see we are creating a management struct using WithClientCredentials so that we can authenticate and WithClient to pass a simple client with a timeout. that client looks like:

const defaultTimeout = time.Second * 30

var GridlineDefaultHTTPClient = &http.Client{
	Timeout: defaultTimeout,
}

Here's an example of some code that is actually using the management struct. In this case, we are trying to retrieve the email associated with an auth0 user:

type EmailGetter struct {
	*management.Management
}

func (g *EmailGetter) Get(userID string) (string, error) {
	u, err := g.User.Read(userID)
	if err != nil {
		logger.Logger.Errorw("failed to get email", "err", err)
		return "", err
	}
	if u.Email == nil {
		return "", errors.New("email was nil")
	}
	return *u.Email, nil
}

sometimes we make the g.User.Read call successfully, but other times we receive this error:
"caller":"auth/auth0.go:73","msg":"failed to get email","err":"context canceled"

what is strange to me is that I don't know how a context could be getting canceled. Looking at the auth0 code, i see that if a context is not provided in neither the management struct nor the g.User.Read call, the context to be used should be context.Background() by default. Please correct me if I'm wrong, but if true, the background context should not be cancellable.

Any help is greatly appreciated, thank you!

Package Version

from our go.mod file:
gopkg.in/auth0.v5 v5.21.1

I was not able to find a version.go file in the auth0 package, apologies if I'm just missing it.

Affected Resources

so far, I have seen this error on User.Read as well as Job.VerifyEmail

Sample Code

sample code is provided above in the description

Expected Behavior

I should never get a context canceled because I am never passing in a context to the management nor its individual calls, so the expectation is I am using context.Background which cannot be canceled

Actual Behavior

requests are returning an error of context canceled

Output

output is provided in the description

References

n/a

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment
@dev-admin-gridline
Copy link
Author

Update: long story short, this is not a Auth0 issue, but rather an issue with go 1.17.3. In case this happens to anyone else, I suggest downgrading to 1.17.2 until go releases a fix.

here's the issue logged in the go github repo: golang/go#49517

couldn't find if they are planning on fixing this soon in a new version.

resp.Body.Close(), even when called correctly, can return an unexpected context canceled in 1.17.3

I was able to test this by vendoring the auth0 code and adding a bunch of log statements to see exactly where the error was coming from. Barbaric, i know, but it worked :D

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant