Add Support for Retry in WP CLI Core Download Command #258
Conversation
src/Core_Command.php
Outdated
| @@ -116,6 +116,12 @@ public function check_update( $_, $assoc_args ) { | |||
| * [--version=<version>] | |||
| * : Select which version you want to download. Accepts a version number, 'latest' or 'nightly'. | |||
| * | |||
| * [--retry=<retry>] | |||
| * : Number of retries in case of failure. Default is 0. | |||
There was a problem hiding this comment.
I think by default it can be 3. Since this retry functionality is in place, a default would be better.
There was a problem hiding this comment.
I am not sure about this part though. If it's just user opt-in, then makes sense to keep it 0?
src/Core_Command.php
Outdated
| if ( $md5_file === $md5_response->body ) { | ||
| WP_CLI::log( 'md5 hash verified: ' . $md5_file ); | ||
| do { | ||
| $md5_response = Utils\http_request( 'GET', $download_url . '.md5', null, [], $options ); |
There was a problem hiding this comment.
Just discussed the retries with @schlessera and the Requests library does provide a way to hook options in curl - https://requests.ryanmccue.info/docs/hooks.html#:~:text=Requests%5Crequest_multiple().-,curl.before_request,-Set%20cURL%20options
#259
Not sure though if we should add it by default in Utils\http_request(). Thoughts @schlessera?
|
We do have a recurring need for retries in several places, so I think it would make sense to add the capability for retries to The only thing to keep aware of is that it already contains a retry mechanism for retrying failed verified requests in an unverified way. The logic will probably end up looking more complex that it should because of that. |
| * | ||
| * [--retry-delay=<retry-delay>] | ||
| * : Delay between retries in seconds. Default is 5 seconds. | ||
| * |
There was a problem hiding this comment.
Given our conversation on Zoom today, I think we should change this slightly.
- Within
wp core download, I think we should only have--retry=<count>as an argument. This will let us be opinionated about exponential backoff. - We can update
Utils\http_request()to support'retry'and'retry_delay'as arguments. - The
--retry=<count>argument should be applied to all HTTP requests withinwp core download.
If WordPress.org is down in some manner, it's not helpful for WP-CLI users to keep hammering it with requests. Their systems should be tolerant to this fault. However, --retry=<count> with exponential (or linear) backoff (5 to ~30 seconds) and a maximum count seems like a good compromise.
We should have some tests!
There was a problem hiding this comment.
@danielbachhuber As discussed in the call, we decided to wrap the whole try-catch block inside the do-while loop to handle the retry feature. But after taking a deeper look into it there are many early and exception throwing that may break the retry loop in between.
We should keep the retry loop in the download command only because updating the http_request util will affect other commands as well.
Description
This PR supports a retry mechanism in the WP CLI core download command. With the addition of --retry= and --retry-delay= flags, users can now specify the number of retry attempts and the delay between retries in case the download fails due to network issues or other transient errors.
Features Added:
--retry=<retry>flag allows users to specify the number of retry attempts in case of download failure. The default value is set to 0.--retry-delay=<delay>flag allows users to specify the delay (in seconds) between retry attempts. The default delay is set to 5 seconds.Usage Examples:
wp core download --retry=5 --retry-delay=10- Downloads WordPress core with 5 retry attempts and a delay of 10 seconds between each attempt.wp core download --retry=3- Downloads WordPress core with 3 retry attempts using the default delay of 5 seconds between each attempt.Issue: #155