Handle exceeding Github rate limits
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 35/100
Research direction
No files or tests are named in the issue. Start by locating the client’s REST and GraphQL request entry points and existing error handling. Define how configurable retries should use the rate-limit headers and backoff guidance, then add coverage showing that rate-limited requests wait or fail according to configuration.
Written by the indexing model from the issue text.
Description
If you exceed your primary rate limit, you will receive a 403 or 429 response, and the x-ratelimit-remaining header will be 0. You should not retry your request until after the time specified by the x-ratelimit-reset header.
If you exceed a secondary rate limit, you will receive a 403 or 429 response and an error message that indicates that you exceeded a secondary rate limit. If the retry-after response header is present, you should not retry your request until after that many seconds has elapsed. If the x-ratelimit-remaining header is 0, you should not retry your request until after the time, in UTC epoch seconds, specified by the x-ratelimit-reset header. Otherwise, wait for at least one minute before retrying. If your request continues to fail due to a secondary rate limit, wait for an exponentially increasing amount of time between retries, and throw an error after a specific number of retries.
Continuing to make requests while you are rate limited may result in the banning of your integration.
It would be nice if simple-github automatically handled this for consumers, though the behaviour should be configurable as there may be cases where consumers would rather schedule other work instead of waiting for the rate limit to grow again.
- Dominant language
- Python
- Stars
- 3
- Forks
- 8
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 9
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from mozilla-releng/simple-github
-
Difficulty 2/5 1-3 hours Newbie friendliness 72/100
mozilla-releng/simple-github#196 · 1 comment ·
-
Dependency Dashboard Open
Difficulty 5/5 Over a week Newbie friendliness 20/100
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
All issues in mozilla-releng/simple-github
Similar issues
-
essnmx good first issue
Difficulty 1/5 Under an hour Newbie friendliness 95/100
-
[Feature] 奇物选择添加优先级 Open
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
syfoud/Simulated_Scepter#174 ·
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
Giskard-AI/giskard-oss#2840 · 1 comment ·
-
A claim comment carrying the issue number is silently declined while the workflow reports success Openarea: repo bug perceived difficulty: 2
Difficulty 2/5 1-3 hours Newbie friendliness 70/100
-
Difficulty 2/5 1-3 hours Newbie friendliness 75/100
yeti-platform/yeti#1380 ·