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

Exponential backoff for access token requests failing due to rate limits #662

Closed
wonderfly opened this issue Jan 10, 2015 · 0 comments
Closed
Assignees
Labels
imported priority: p2 Moderately-important priority. Fix may not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.

Comments

@wonderfly
Copy link
Contributor

From yan...@google.com on November 02, 2012 05:17:46

copied from: https://code.google.com/p/google-oauth-java-client/issues/detail?id=57 Version of google-oauth-java-client (e.g. 1.5.0-beta)?
1.12.0-beta

Java environment (e.g. Java 6, Android 2.3, App Engine)?
Java 6, presumably non-AppEngine unless you're not using the AppEngine robot credentials.

Describe the problem.

  1. Share the refresh token with 10+ machines.
  2. Perform an authenticated API request across the same machines simultaneously.
    Expected: Eventual success.
    Actual: Access denied error.

How would you expect it to be fixed? https://code.google.com/p/google-oauth-java-client/source/browse/google-oauth-client/src/main/java/com/google/api/client/auth/oauth2/TokenRequest.java#303 https://code.google.com/p/gsutil/source/browse/trunk/src/oauth2_plugin/oauth2_client.py#343 The problem is that if you have many machines hitting the token endpoint for the same refresh token, you will hit the rate limit and further requests will yield 403 without any computer-readable indication that you've hit a rate limit (there is human-readable HTML in the response that so indicates). We need to treat 403s as if they were a 429 ( http://tools.ietf.org/html/rfc6585 ) and, without a Retry-After field, just use exponential backoff to try and get a refresh token. (If a Retry-After field were available, use it to establish a baseline for adding extra delay.)

This will not fix the underlying problem, but it will amelioriate it, and slowly machines will be able to start work.

In this case, we cannot expect that the response will contain JSON, so we'll have to fall back on raw HTTP code handling.

My comment:

Problem is we have no good way yet of knowing that a 403 is recoverable. Another potential source of 403 for Google APIs is if the API hasn't been enabled in the APIs Console. So we need a reliable way of detecting that. One possibility is to read the human-readable HTML, but that seems prone to fail in the future. So at this point I don't have a concrete proposal yet, and therefore I'll keep it as Low priority, but I'll keep it open until we do.

Original issue: http://code.google.com/p/google-api-java-client/issues/detail?id=648

@wonderfly wonderfly added type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design. imported Component-Auth labels Jan 10, 2015
@wonderfly wonderfly self-assigned this Jan 10, 2015
@wonderfly wonderfly removed their assignment May 19, 2016
@JustinBeckwith JustinBeckwith added priority: p2 Moderately-important priority. Fix may not be included in next release. and removed Priority-Low labels Jun 7, 2018
@JustinBeckwith JustinBeckwith self-assigned this Feb 1, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
imported priority: p2 Moderately-important priority. Fix may not be included in next release. type: feature request ‘Nice-to-have’ improvement, new feature or different behavior or design.
Projects
None yet
Development

No branches or pull requests

2 participants