Remove Failure/Retry strategy?

[joshribakoff]

I noticed it automatically retries the API 5x in the event of a failure, even if that failure is deterministic. For example if you put the wrong repository name it keeps retrying as if that repository is going to exist on subsequent tries.

It also seems to have no sleep() period between retries.

Personally I think this functionality should be removed completely or rewritten completely. When doing some manual testing I quickly hit the API rate limit 5x sooner due to this.

That's the only legitimate reason I can come up with, but I hope you'll agree retrying the request when the credentials are bad, for example, is pointless.

[joshribakoff]

Also there's some succinct bash scripts floating around on stackoverflow for retrying a command with a sleep interval until it exits 0. And perhaps we could make a separate project, a command for running other commands until they succeed. Could use Zend\Console\Adapter to accept CLI flags for the number of times to retry, how long to sleep, what kinds of exit codes to retry for, etc.. with some sane defaults. The 'backoff'/retry logic is outside the scope of generating a github changelog. This backoff tool should be generic enough to use with any linux command(s), for example for rsync backups that fail and need to be restarted until they finish. There could be some kind of timeout/max # of restarts before it gives up.

[weierophinney]

I noticed it automatically retries the API 5x in the event of a failure, even if that failure is deterministic.

The "5x" in there is actually to ensure I get all pages of issues for a given milestone.

GitHub limits the number of results for any given API call to 200. I've found that I rarely have more than 100, and so if you look carefully, I've set the per_page value to 100. The bulk of the routine is checking the Link header to see if there are more pages for me to get, and, if so, I fetch those. I put a hard limit at 5 tries, however, because GitHub always reports a "next" relation if there is more than one page, but does not indicate when there is a "last" relation -- which means you can eat up your API calls by hitting the last page over and over again.

Technically, if you get an error, you should bail early; however, the error handling is very rudimentary.

The routine could definitely be smarter; however, given appropriate configuration, it works and only introduces 5 API calls at most. I'd love to see a PR that does better error handling; I simply haven't had a reason to develop it yet at this point.