Client.RateLimits shouldn't return RateLimitError

[sa-spag]

👋 Hello,

I noticed that Client.RateLimits can return a RateLimitError, as per:

go-github/github/github.go

Lines 648 to 652 in 75644ea

	return &RateLimitError{
	Rate: rate,
	Response: resp,
	Message: fmt.Sprintf("API rate limit of %v still exceeded until %v, not making remote request.", rate.Limit, rate.Reset.Time),
	}

According to GitHub REST API documentation, rate limit status can be checked "at any time using the Rate Limit API", i.e. even when the remaining number of allowed requests is 0, and the GET /rate_limit endpoint never responds with a HTTP 403. I verified myself and I can confirm the documentation is accurate. Therefore, I think Client.RateLimits should never return RateLimitError errors and return the actual rate limit status, by performing a HTTP request.

I have 2 solutions in mind:

• Client.checkRateLimitBeforeDo is aware of some allowlist of endpoints, including GET /rate_limits (and perhaps others I don't know yet about), for which it should always return nil;
• a higher layer passes a boolean which indicates that the request should not be subject to the pre-request rate limit check, possibly exposed to the user so one could hit GitHub API regardless of the internal rate limit status.

Happy to discuss any solution before I (or someone else) patch(es) the issue. Thanks!

[gmlewis]

May I please ask what the actual problem is that you are trying to solve?

In other words, why is it a problem that Client.RateLimits() returns a RateLimitError (which, by the way, should have all the information you need to avoid causing the next rate limit error... specifically the Reset timestamp)?

[sa-spag]

May I please ask what the actual problem is that you are trying to solve?

RateLimitError only exposes the rate limit status for the request's category, i.e. core for GET /rate_limits, but there are a bunch of other "resources" for which rate limit is independent and for which I would like to request an up-to-date status.

[gmlewis]

I suppose a third option is to modify Client.RateLimits() to always perform the call regardless of saved history by bypassing the existing check.

[sa-spag]

I suppose a third option is to modify Client.RateLimits() to always perform the call regardless of saved history by bypassing the existing check.

Thanks for your feedback. Exactly, and I think we have at least 2 ways of implementing such bypass mechanism (the 2 options I previously listed). Do not hesitate to provide any guidance to take a decision.

[gmlewis]

My current thought is to not add to the complexity of Client.checkRateLimitBeforeDo() but instead modify only Client.RateLimits() as necessary to implement this change.

I'm fine for you to go ahead and create a PR if you are interested, @sa-spag, and let's see what it looks like.