Rate limiting
GitHub enforces secondary rate limits that can throttle or block your application if it makes too many requests in a short period. This extension provides two complementary mechanisms to handle them: proactive throttling and retry on failure.
Proactive throttling
Proactive throttling adds configurable delays between API calls to avoid triggering secondary rate limits in the first place.
It is enabled by default in production and dev mode, and disabled in tests.
Using GitHubApiUtil
The io.quarkiverse.githubapi.GitHubApiUtil class provides convenience methods for throttled operations.
Throttled pagination with toStream()
When iterating over paginated results, use toStream() to automatically add a delay between page fetches:
import io.quarkiverse.githubapi.GitHubApiUtil;
import org.kohsuke.github.GHRepository;
List<GHRepository> repos = GitHubApiUtil.toStream(gitHub.getMyself().listRepositories())
.filter(r -> !r.isArchived())
.toList();
Manual throttling
For fine-grained control, call the sleep methods directly:
import io.quarkiverse.githubapi.GitHubApiUtil;
for (GHIssue issue : issues) {
issue.addLabels("triaged");
GitHubApiUtil.sleepForWriteThrottling();
}
for (GHRepository repo : repos) {
repo.getReadme();
GitHubApiUtil.sleepForReadThrottling();
}
Retry on secondary rate limit
When a call is denied due to a secondary rate limit, the underlying Hub4j library automatically retries it.
You can configure the maximum number of retry attempts via quarkus.github-api.rate-limit.retry.max-attempts (defaults to 2).
See the Configuration reference for the full list of configuration properties.