GitHub API rate limiting

[Callum-Mitchell]

Like Slack, the GitHub API is subject to certain rate limits as follows:

• User-to-server requests: 5000 per hour per GitHub user (shared between user's GitHub apps) --- https://developer.github.com/apps/building-github-apps/understanding-rate-limits-for-github-apps/
• Search API requests: 30 per minute per GitHub user. This includes things like getting all commits in a repository by a specific user in a specific date range, or any other calls that search for and return lists of values --- https://developer.github.com/v3/search/

Exceeding either rate limit will trigger an abuse detection system and block any further API requests until the limit is reset.

The Search API limit is our main concern, as certain jobs such as getting all comments by a user on all issues/PRs within each of their repositories may use more than 30 search requests.

A few potential ways to handle this:

• "Quick and dirty" short-term solution: wait 2-3 seconds between each search request using manual delays
• Robust long-term solution for scalability: asynchronous/interrupt-driven architecture (example: perform search query for a given user until 20 searches have been made, then interrupt this (to be resumed after a minimum of 1 minute), then immediately start working on the next user's job and do another 20 searches for them, interrupt....repeat until all users covered, then start again (waiting until 1 minute if necessary), do this until all users' jobs are complete.)

The long-term solution will take some work/design tweaking. While we have only a few users (the three of us), simply delays are acceptable and are currently being used to avoid jobs being blocked, at the expense of some taking a few minutes to complete.

[Callum-Mitchell]

Quick and dirty solution is in place already. Long-term solution can be tackled after panel exam.