-
Notifications
You must be signed in to change notification settings - Fork 726
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
Github Repository Search resulting in Secondary Rate Limit #1842
Comments
I was able to achieve this using:
And then instead of calling the toList on the PagedSearchIterable, I iterated the result using nextPage, like this:
|
Reopening as this is an interesting case for Secondary rate limits. |
See also #1805 |
This docs page describes secondary rate limit behavior: As of this reading it says:
These are incredibly loosely defined guides and you cannot query for them ahead of time. 👎 It looks like we need to take the path some users have suggested and make rate limiting much more resilient, potentially allowing users to write their own rate limit strategies for handling secondary rate limits. |
From my perspective, I'd be happy with a default strategy which just detects the error and sleeps. In the worst case, detection could be based on pattern matching to the That's more or less what I'll have to implement in the client, but it would be convenient if it were implemented centrally. A customisable strategy might be a nice-to-have on top of that, but I think "go slow, but make the request succeed" is probably what most clients would want. Or maybe that's an assumption I'm making? |
@holly-cummins Unfortunately, GitHub has previously made it clear that it is the responsibility of clients toby well-behaved. Triggering the secondary rate limit too often may eventually get accounts or apps flagged for "abuse", resulting in even longer waits. The problem is "good behavior" is poorly defined and subject to change without notice. "Go slow" sure, But how slow? They have a metric, but they expect the client to track it, rather than reporting it like they do with the primary rate limit. |
I was really excited to try 1.322, but am still seeing fairly regular failures because of the rate limit even with 1.322. I have some node.js code that uses the GitHub API, and I did manage to work around the secondary errors with |
Describe the bug
Getting the below error when searching for repositories with a keyword that returns a lot of repositories in the result. My usecase can be fulfilled by just getting say top 50 results, but I do not see any way to do that on the server side but only post getting the results.
I was trying the search for repositories within my org and keywords that matched even around 850 repositories were hitting this rate limit. The github documentation quotes a much larger number.
I even tried the
in:name
andin:displayName
within the query but even that did not seem to help.To Reproduce
Steps to reproduce the behavior:
Just pass in a repo name like "test" or something that results in a lot of repository results in the above code.
Expected Behaviour
It should return the repositories or else provide a clear reason of why the error. Or else there should be a way to limit the search results on the GitHub side itself.
Additional Info
Version: org.kohsuke:github-api:1.316
The text was updated successfully, but these errors were encountered: