Retry strategy on rate limit

[dblock]

Coming from #1489 I am attempting to handle the rate limit as follows.

module GitHub
  module RateLimited
    def rate_limited(&_block)
      suspend_s = 5
      begin
        yield if block_given?
      rescue Octokit::TooManyRequests => e
        sleep suspend_s
        suspend_s = [suspend_s * 2, client.rate_limit.resets_in + 1].min
        retry
      end
    end
  end
end

There are a few problems here.

1. It's not built into auto-pagination in octokit, so the entire set of pagination requests will be retried. Is there a better implementation?
2. The rate_limit.resets_in value does not seem like the right amount of time to wait. It is the entire duration till the next reset, even before I have consumed all requests. How do I obtain the time when I will be allowed to make the next request, aka the cool down time?
3. Is this something we should/can build into Octokit? I can give it a shot.

[nickfloyd]

@dblock Thanks for reaching out about this! ❤

Regarding rate limits, currently, the SDK doesn't have a great way to bubble that up to you. While the rate limit information is present in the HTTP headers of the request coming back from the REST API call, no logic or method calculates the "cool down time."

Take a look at client/rate_limit.rb and rate_limit.rb to see if any implementations in there might help.

Given that we don't yet support generative models and do not have pagination implemented, we'd welcome any contributions to paging that you'd be providing. Please feel free to submit a PR with your thoughts about auto-pagination.