gofri / go-github-ratelimit Goto Github PK

I'll preface this with saying my use case here might be a little niche.

I'm using go-github-ratelimit in a Kubernetes controller where I have a pool of go-github clients allocated. Because of the nature of the controller, it's not feasible to wait/block for significant periods of time. Instead, it's preferable for the controller to requeue and reattempt later.

I've defined a callback function that cordons off the affect client until the wait period is over, and allows the HTTP request to fail/return an error. At which point, the controller will requeue and reattempt with a different client. However, go-github-ratelimit is still waiting outside of the callback function, and reattempting the request.

Basically what I'm wondering is, is it possible to use go-github-ratelimit to catch the Secondary rate limit error, execute some callback function, and then allow the request to fail, without waiting?

My current alternative is to manually check the response from go-github for a secondary rate limit error and do the necessary steps there, but being able to do this in a package would be nice 🙂

Hi,

I have some code that intiializes a go-github client using go-github-ratelimiter, with a custom callback function defined like so:

rateLimiter, err := github_ratelimit.NewRateLimitWaiterClient(tc.Transport, github_ratelimit.WithLimitDetectedCallback(func(cbContext *github_ratelimit.CallbackContext) {
		ctx := *cbContext.UserContext
		// Some other steps
}))
client := github.NewClient(rateLimiter)

But despite using a GitHub token that is secondary rate limited (for content creation), I don't ever see the callback function run.

I'm using github.com/gofri/go-github-ratelimit v1.0.2 and github.com/google/go-github/v41 v41.0.0

Unlike secondary rate limits, primary rate limits are long and categorized.
As a result, sleeping is not obviously the natural response for them, and the implementation must be aware of the categories.

Options (not mutually exclusive):

• Add a callback for when a primary rate limit is detected (no need for category awareness).
• Handle the different categories and implement a complete solution (maybe with more freedom regarding the user's response).
• Provide it as a separate RoundTripper.
• Provide wrapper functions to stack them.

The API documentation states that the x-ratelimit-reset header should be used for secondary rate limits if the Retry-After header is missing.
Although in practice I only encountered this header for the primary rate limits, let's just follow the guidelines.
https://docs.github.com/en/rest/guides/best-practices-for-integrators?apiVersion=2022-11-28#dealing-with-secondary-rate-limits