rate_limit doesn't always return valid information

[theckman]

If you use Octokit in a long running piece of software with infrequent API calls, the rate_limit Client method can return stale/invalid date.

I've taken a quick glance at the code and it looks like the rate limit information is pulled from the headers of the last request. After some time the information itself becomes stale, and eventually the resets_in field in the Struct becomes a negative number. This happens because time has progressed past the resets_at time, yet the information hasn't been refreshed.

Is there a reason why the /rate_limit API endpoint isn't used?

[pengwynn]

After some time the information itself becomes stale, and eventually the resets_in field in the Struct becomes a negative number.

Yeah that logic could be smarter.

Is there a reason why the /rate_limit API endpoint isn't used?

For high volume clients, this can save a number of server round trips. A patch to check resets_in vs the current time would be welcome.

[theckman]

Thanks for getting back to me.

I'll try to allocate some time to take a look improving the intelligence. Is it OK if I keep this issue open until I, or someone else, provides a PR?

[pengwynn]

@theckman Sure thing.