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

Retreive response headers #742

Closed
Elvin087 opened this issue Sep 20, 2022 · 6 comments · Fixed by #744
Closed

Retreive response headers #742

Elvin087 opened this issue Sep 20, 2022 · 6 comments · Fixed by #744
Labels
Feature Request A feature has been asked for or suggested by the community

Comments

@Elvin087
Copy link

Describe the problem you'd like to have solved

Using the management API to retrieve users which works fine. Now I need to have access to the response headers to tackle a rate limiting issue. Like described here. I need to have access to the auth0 response headers x-ratelimit-limit, x-ratelimit-remaining and x-ratelimit-reset. I was not able to get the response headers from auth0.

While checking the management api code I found out that the headers from the rest-fasade (used client) are not being passed back to the results.

The ideal solution

I would like to be able to get the headers together with the response body.

const auth0ApiClient = new ManagementClient(...)
auth0ApiClient.getUser({ id: customerId }.then((body, headers) => {
    console.log("Headers: ", headers)
})

Let me know If there is a workaround within the management API to solve this issue.

@adamjmcgrath
Copy link
Contributor

HI @Elvin087 - thanks for raising this

We don't expose rate-limit headers from those requests but instead apply our own rate limit strategy of exponential backoff, which we think is suitable for this api. Could you tell me a bit more about your use case and whether you can use the SDKs rate limit handling?

@Elvin087
Copy link
Author

Hi @adamjmcgrath, thank you for getting back to me.

I did see the retry meganism with exponential backoff. In most case that should work perfectly.
In our case we are running "tools / background jobs" in the back-end that might fetch allot of users hitting the rate limit. We want to avoid impacking users coming from our front-end with these back-end jobs. By checking the 3 headers mentioned ealier we want to pauze the background jobs to not impack the users.

Example:

When the response header x-ratelimit-remaining header gets to low we want to pause the background jobs till more slots are available.

{
  'x-ratelimit-limit': '500',
  'x-ratelimit-remaining': '50',
  'x-ratelimit-reset': '1663680011'
}

What are your thoughs on this?

@adamjmcgrath
Copy link
Contributor

Hi @Elvin087 - thanks for sharing your use case, sounds reasonable.

auth0ApiClient.getUser({ id: customerId }.then((body, headers)

Promises can only resolve a single value (and I'm reluctant to have a different api for callbacks and promises).

But, since this has come up a couple of times recently, perhaps we can add an option that will add headers, in addition to the body, to the return value, eg

const auth0ApiClient = new ManagementClient(..., withHeaders: true) // name tbc
auth0ApiClient.getUser({ id: customerId }).then(({ body, headers }) => ...);

I've already created a PR to refactor the Management clients a little to make this type of thing a little easier to support #743

I don't have an idea of when I might complete this, but will leave this open as a feature request for now.

@adamjmcgrath adamjmcgrath added Feature Request A feature has been asked for or suggested by the community and removed question labels Sep 22, 2022
@Elvin087
Copy link
Author

Hi @adamjmcgrath,

Would be great to so see this feature implemented. Might be helpfull to others also.
I'll check in a while to see if any progress is made on this subject. Thank you!

@adamjmcgrath
Copy link
Contributor

@Elvin087
Copy link
Author

@adamjmcgrath this is very well appreciated. Thank you 🥇 .

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Feature Request A feature has been asked for or suggested by the community
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants