-
-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Remove Failure/Retry strategy? #7
Comments
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. |
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 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. |
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.
The text was updated successfully, but these errors were encountered: