Occasionally the GH CI Actions fail on when running the “fetch configlet” step.
curl fails with an HTTP 403 error but typically succeeds on retry: curl: (22) The requested URL returned error: 403.
I discussed this with @BethanyG and we believe this is likely caused by a GH Rate Limit Exceeded error. (Yes, a rate limit response ought to be 427 but it appears GH uses 403. This is not an Exercism-specific bug with the response codes.)
Some viable options here are listed below. If you just want my thoughts on what’s the best for now, skip to the last bullet 
- Do nothing. Maintain the current state. Typically this means having a maintainer manually retry the step.
- Implement rate limiting across repo CIs. I’m not familiar with GH actions but I suspect synchronizing data across repo actions may be … tricky.
- Cache the configlet somewhere off GH. This would involve running an additional service/cache, which is an “expensive” route.
- Change the “fetch” pull model to a push model. e.g. on a configlet update, push the new configlet to all the repos. This avoids the whole rate limit issue but means changes to the configlet requires pushing a bunch of PRs and shepherding those across a large number (60? 150?) of repos.
- Add retry logic (e.g. 3 retries, exponential backoffs with jitter, etc; or, parse the response and see if the response contains a “try again in N seconds”) to the “fetch configlet” logic. This isn’t a perfect solution as it will simply fail again, and harder, if we’re consistently running near the limit. However, if we only occasionally get rate limited, this is a relatively simple and low cost solution.
Tagging @ErikSchierboom @kytrinyx for thoughts.