No request leaves the process while GitHub is rate limited (#437, PR #452)
A second report on #437: after the v3.37.0 change, hitting the GitHub rate limit no longer stuck the scheduler, but every other request already queued in the run still went to GitHub and came back 403, and the retry helper sent each of them three more times. GitHub counts requests made while limited toward abuse detection, and one user's account was suspended for it.
- Every GitHub client now holds its requests while the source is paused. A limit that resets within two minutes is waited out inside the request; a longer one fails the request at once without contacting GitHub. Only the rate limit probe endpoint stays open, so the pause can end early when GitHub reports budget again.
- The retry helper no longer retries a rate limit refusal and stops starting the remaining items of the batch.
- A refusal inside the issues, pull requests, releases, labels or milestones pass fails the repository instead of moving on to the next component. The scheduler already puts such a repository back to its previous status and retries it a minute after the reset; with the incremental sync from v3.39.0 the watermark stays put as well.
- A secondary rate limit pauses the whole client for its retry-after window, not only the request that was told to slow down.
If you upgrade from v3.37.0 or later, no action is needed. If your GitHub account was suspended for abuse detection, that is lifted by GitHub Support, not by a new token.
Full Changelog: v3.40.0...v3.40.1