At Acorns, we have some seriously cool Continuous Integration (CI) going on. Basically, whenever we create a pull request on our Git repository, CircleCI (a CI tool) will also build that commit sha in all 3 environments.
Then, like the grand finale of a symphony, the CI delivers the 3 build urls in a neat and tidy GitHub comment, using the @octokit/rest package to access the GitHub API. Voilà.
When I first came to Acorns, I thought that was so gansta! (At my last workplace, we deployed our builds to each environment manually one-by-one…the horror!)
Sometimes, we got “Rate Limit Exceeded” errors.
HOWEVER, despite this cool feature, some things were not cool. Every now and then, we would get a 403 error from GitHub:
Rate Limit Exceeded
When all 3 builds successfully built, but this one github-comment step failed, it was almost always this same error, Rate Limit Exceeded. When this step of writing a GitHub comment failed, then we couldn’t pass all of our required checks, and when we don’t pass all of the required checks, we can’t merge our feature branch in. What the hell?!!! It’s not even a real error! At least what I mean is that it’s not an issue with my branch. My builds passed, my tests passed, linting passed, and it’s just this one snarky GitHub comment that is erroring and slowing me down.
What does “Rate Limit Exceeded” mean?
After a few times of this happening and going away and happening again, I decided enough was enough. Like a good software engineer, I finally asked the question, “Why?”
Basically what is happening is that GitHub has a limit of how many requests could be sent per hour. Normally, the standard limits for the GitHub API are:
Unauthenticated – 600 requests per originating IP address
Authenticated – 5,000 requests per hour per user
However, if you want to be more precise, you can also see the x-ratelimit-limit response header, which is 5000 in our example. On the CI tool, since we setup the workflow with the same bot user to write this comment, we eventually hit this limit with so many Acorns developers working so hard! 😀
How do I know when I can call the GitHub API again?
Great question! When you receive the error response, you will see a response header, x-ratelimit-reset with a value. This number value is basically the time that this rate limit will be reset, meaning it is the time when you can call the GitHub API again without a rate limiting error.
In this example, the response contains x-ratelimit-reset: '1598048562'. This string of numbers indicates a date and time in Epoch time. Epoch time is the “number of seconds that have elapsed since January 1, 1970.”
To find out what the human readable date and time is, I use EpochConverter. Once I paste in 1598048562 (Epoch time) and press “Timestamp to Human date,” it shows me that 1598048562 is the same as Friday, August 21, 2020 3:22:42 PM in Local Time.
This means that on Friday, August 21 at 3:22pm (the Epoch value of x-ratelimit-reset header) or afterwards, I can call the GitHub API again without a problem. I have to wait some time (less than an hour usually), but other than that, success!
However, the better solution (but requires more work up-front) is to create and implement multiple users for GitHub comments. Since the rate limit applies to the number of requests to GitHub API per user, splitting the total number of API requests by several GitHub users would drastically reduce the chances of ever hitting the rate limit. For example, if I have 5000 requests per hour and 2 GitHub users, then each user only needs to create 2500 requests, which is well below the rate limit. #themoreyouknow