Exponential backoff for access token requests failing due to rate limits #662
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.
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.
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
The text was updated successfully, but these errors were encountered: