Error: RuntimeException: Failed to get url when using `wp core verify-checksums`

[rumspeed]

Bug Report

• [x] Yes, I reviewed the contribution guidelines.
• [x] Yes, more specifically, I reviewed the guidelines on how to write clear bug reports.

Describe the current, buggy behavior

Running wp core verify-checksums fails when the .org API server times out and throws a RuntimeException . A timeout should be handled gracefully, and an error or warning thrown instead. Here is the exception error.

Error: RuntimeException: Failed to get url 'https://api.wordpress.org/core/checksums/1.0/?version=+%276.0&locale=en_US': cURL error 28: Operation timed out after 10000 milliseconds with 0 out of -1 bytes received.

This was reported in the Slack #cli channel on June 30th. It was also noted the the URL version number contains extra characters but still returns the checksum payload.

Describe how other contributors can replicate this bug

NOTE: This will be difficult to replicate unless you can simulate the .org API server timing out because it works 99.99% of the time.

• run wp core verify-checksums
• inspect output for exception error

Describe what you would expect as the correct outcome

A warning (or error) should be returned instead of the command throwing an exception error.

Let us know what environment you are running this on

OS:	Linux 3.10.0-327.18.2.el7.centos.plus.x86_64 wp-cli/core-command#1 SMP Fri May 13 02:05:28 UTC 2016 x86_64
Shell:	/bin/bash
PHP binary:	/usr/bin/php
PHP version:	7.4.30
php.ini used:	/etc/php.ini
MySQL binary:	/bin/mysql
MySQL version:	mysql  Ver 15.1 Distrib 10.1.48-MariaDB, for Linux (x86_64) using readline 5.1
SQL modes:	
WP-CLI root dir:	phar://wp-cli.phar/vendor/wp-cli/wp-cli
WP-CLI vendor dir:	phar://wp-cli.phar/vendor
WP_CLI phar path:	/home/oowygruc6apk5l7u4dxvchhjz/public_html
WP-CLI packages dir:	
WP-CLI global config:	
WP-CLI project config:	
WP-CLI version:	2.6.0

[danielbachhuber]

Running wp core verify-checksums fails when the .org API server times out and throws a RuntimeException . A timeout should be handled gracefully, and an error or warning thrown instead. Here is the exception error.

@rumspeed Thanks for the report!

I think what you're seeing is WP_CLI:error() handle the RuntimeException:

https://github.com/wp-cli/checksum-command/blob/310c4c549fcb1f73ad968f686459ff195a07d441/src/Checksum_Core_Command.php#L84-L88

https://github.com/wp-cli/wp-cli/blob/e067300a97ab3757e55c3c5beba8cff3d89d3340/php/WP_CLI/WpOrgApi.php#L314-L335

Could you share a bit more detail on the error you'd expect to see?

[rumspeed]

Thank you for replying @danielbachhuber.

Could you share a bit more detail on the error you'd expect to see?

In the Slack #cli channel on June 30th I was initially questioning if the API service was not working or maybe overloaded based on the Error: RuntimeException: Failed to get url message I was getting.

@schlessera responded to with "The fact that the command throws a RuntimeException in this case is a bug, though." and shortly after that we agreed that I would add an issue to the GitHub repo for a deeper look.

If this isn't a but then go ahead and close this out. :)

[rumspeed]

The wordpress.org API failed a few more times recently using the wp core verify-checksums command. I confirmed that the return code was a 400. With this being a server issue, as it is reporting RuntimeException: Failed to get url, should this be a 503 Service Unavailable?

[danielbachhuber]

I confirmed that the return code was a 400. With this being a server issue, as it is reporting RuntimeException: Failed to get url, should this be a 503 Service Unavailable?

@rumspeed Just to confirm, 400 was the return code from wordpress.org?

If this is the case, I think the problem you're referring to would be better fixed upstream.

[schlessera]

Yes, this is definitely an issue with the upstream server.

However, given this seems a common occurrence with the WP.org APIs, I would also consider adding a retry mechanism to this command, to improve its resilience.

[rumspeed]

Thank you for the reply @danielbachhuber. The 400 code I am seeing is returned from the WP_CLI::error( $exception ) payload.

@schlessera, is there anything else I can do to help with this?