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

RateLimitHandler Bug #220

Closed
anschwar opened this issue Sep 29, 2015 · 11 comments
Closed

RateLimitHandler Bug #220

anschwar opened this issue Sep 29, 2015 · 11 comments

Comments

@anschwar
Copy link

Hi,

the RateLimitHandler does not to work as intended.
If using the WAIT implementation the API will still throw an exception and terminate.

The reason therefore is that there is no return statement after the handler execute its onError method.
The problem is allocated in the handleApiError method of the Requester.

https://github.com/kohsuke/github-api/blob/master/src/main/java/org/kohsuke/github/Requester.java

@KostyaSha
Copy link
Contributor

Any prove? Any logs? Any test case? What exception?

@KostyaSha
Copy link
Contributor

Do you use Enterprise github? Could you provide PR with fix?

@anschwar
Copy link
Author

First of all the old code looked like this (1.60)

/*package*/ void handleApiError(IOException e, HttpURLConnection uc) throws IOException {
    if ("0".equals(uc.getHeaderField("X-RateLimit-Remaining"))) {
        // API limit reached. wait 10 secs and return normally
        try {
            Thread.sleep(10000);
            return;
        } catch (InterruptedException _) {
            throw (InterruptedIOException)new InterruptedIOException().initCause(e);
        }
    }

...

This is nearly the implementation of the current WAIT. It waits 10 seconds and then returns without an exception. The current branch handles the error and then still throws an IO exception

Second. I am fairly new to github and i don't have enterprice github. Is it still possible to provide an PR?

@KostyaSha
Copy link
Contributor

Please provide exception reason, not all exceptions should be waited.

@anschwar
Copy link
Author

Exception in thread "main" java.lang.Error: java.io.IOException: {"message":"API rate limit exceeded for anschwar.","documentation_url":"https://developer.github.com/v3/#rate-limiting"}

@KostyaSha
Copy link
Contributor

on email i see full stacktrace

Caused by: java.io.IOException: Server returned HTTP response code: 403 for URL: https://api.github.com/search/repositories?q=language%3AScala&page=31

@anschwar
Copy link
Author

Yes I posted the full one but then i mentioned that you only requested the reason so I edited my comment. However this seems for me to be a consequence of the rate limit.

If you think the behavior of the API is correct, I am ok with it

@KostyaSha
Copy link
Contributor

The logic was the next, if you pass wrong user and it not authorised (403) it should throw exception either you will be unable to stop this connection and change user.

@anschwar
Copy link
Author

I am able to retrieve results (so my credentials are ok) until a certain point.

I have debugged the code and saw that the handler waits certain time until it should return to work again. But this never happens because the code checks the result which has been received before waiting and then throws the exception which imo seems to be wrong.

@anschwar
Copy link
Author

anschwar commented Oct 1, 2015

I found this in the official github api documentation:

Once you go over the rate limit you will receive an error response:

HTTP/1.1 403 Forbidden
Date: Tue, 20 Aug 2013 14:50:41 GMT
Status: 403 Forbidden
X-RateLimit-Limit: 60
X-RateLimit-Remaining: 0
X-RateLimit-Reset: 1377013266

{
"message": "API rate limit exceeded for xxx.xxx.xxx.xxx. (But here's the good news: Authenticated requests get a higher rate limit. Check out the documentation for more details.)",
"documentation_url": "https://developer.github.com/v3/#rate-limiting"
}

The 403 is returned if the rate limit is reached

kohsuke added a commit that referenced this issue Dec 2, 2015
Issue #220. If RateLimitHandler returns normally, it should retry.
@kohsuke
Copy link
Collaborator

kohsuke commented Dec 2, 2015

Fixed in 1.72.

@kohsuke kohsuke closed this as completed Dec 2, 2015
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants