Opened 12 months ago
Last modified 5 months ago
#51669 reopened defect (bug)
Reduce misleading test failures caused by HTTP timeouts, take 2
Reported by: |
|
Owned by: |
|
---|---|---|---|
Milestone: | 5.9 | Priority: | normal |
Severity: | normal | Version: | |
Component: | Build/Test Tools | Keywords: | has-patch |
Focuses: | Cc: |
Description (last modified by )
Background: #44613.
During the 5.5.2 release and subsequent backports all the way to the 3.7 branch, there were quite a few test failures caused by HTTP timeouts. Some examples of these, collected by @desrosj:
1) Tests_HTTP_curl::test_redirect_on_head Connection timed out after 5001 milliseconds Failed asserting that WP_Error Object (...) is not an instance of class "WP_Error". 1) Tests_HTTP_curl::test_redirect_on_head Failed asserting that true is false. 1) Tests_HTTP_curl::test_redirect_on_302 Failed asserting that true is false. 1) Tests_HTTP_Functions::test_get_response_cookies Failed asserting that an array is not empty. 1) Tests_HTTP_streams::test_redirect_on_301 stream_socket_client(): unable to connect to tcp://api.wordpress.org:80 (Connection timed out) 1) Tests_HTTP_streams::test_no_head_redirections cURL error 28: Connection timed out after 5000 milliseconds Failed asserting that WP_Error Object (...) is not an instance of class "WP_Error".
These are already fixed in 4.9 or later branches by [43511], [43512], [46682], and [46996]. These changes should be backported to earlier branches too.
There were, however, some other failures in the REST API plugin controller tests:
1) WP_REST_Plugins_Controller_Test::test_create_item_and_activate_errors_if_no_permission_to_activate_plugin An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the <a href="https://wordpress.org/support/forums/">support forums</a>. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) 1) WP_REST_Plugins_Controller_Test::test_create_item_and_network_activate Download failed. Failed asserting that WP_Error Object (...) is not an instance of class "WP_Error". 1) WP_REST_Plugins_Controller_Test::test_create_item An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the <a href="https://wordpress.org/support/forums/">support forums</a>. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.)
These tests are not in the external-http
group. Looking closer, they appear to set up the plugin download to come locally instead of downloading it from WordPress.org, so it's not quite clear why they still attempt to connect to WordPress.org. This will need more investigation.
Attachments (1)
Change History (42)
This ticket was mentioned in Slack in #core by sergey. View the logs.
12 months ago
#4
follow-up:
↓ 6
@
11 months ago
- Description modified (diff)
Just noting that failures/errors in WP_REST_Plugins_Controller_Test
also occasionally happen on trunk too, as seen in this run on GitHub Actions for example.
This ticket was mentioned in Slack in #core by sergey. View the logs.
10 months ago
#6
in reply to:
↑ 4
@
10 months ago
- Keywords has-patch commit added
Replying to SergeyBiryukov:
Just noting that failures/errors in
WP_REST_Plugins_Controller_Test
also occasionally happen on trunk too, as seen in this run on GitHub Actions for example.
Looking at the stack trace, this is an issue similar to [49491] / #51670:
- The plugin installation tests added in [48242] / #50321 run
WP_REST_Plugins_Controller::create_item()
. WP_REST_Plugins_Controller::create_item()
runsPlugin_Upgrader::install()
.Plugin_Upgrader::install()
runs theupgrader_process_complete
action.- The action has these four functions attached to it via
wp-admin/includes/admin-filters.php
:add_action( 'upgrader_process_complete', array( 'Language_Pack_Upgrader', 'async_upgrade' ), 20 );
add_action( 'upgrader_process_complete', 'wp_version_check', 10, 0 );
add_action( 'upgrader_process_complete', 'wp_update_plugins', 10, 0 );
add_action( 'upgrader_process_complete', 'wp_update_themes', 10, 0 );
- [49491] / #51670 cancels the language pack updates using the
async_update_translation
filter, but none of the other three functions have a short-circuit like that. - Ultimately, this causes external HTTP requests that are unnecessary for plugin installation tests and interfer with the results in case of a timeout.
51669.diff fixes the issue in my testing. This is consistent with WP_Automatic_Updater::run()
or Language_Pack_Upgrader::bulk_upgrade
, where these hooks are also removed due to not being needed.
#37
follow-up:
↓ 38
@
9 months ago
- Keywords commit removed
- Resolution fixed deleted
- Status changed from closed to reopened
Got this again when running multisite tests:
There was 1 error: 1) WP_REST_Plugins_Controller_Test::test_create_item An unexpected error occurred. Something may be wrong with WordPress.org or this server’s configuration. If you continue to have problems, please try the <a href="https://wordpress.org/support/forums/">support forums</a>. (WordPress could not establish a secure connection to WordPress.org. Please contact your server administrator.) /var/www/build/wp-admin/includes/plugin-install.php:183 /var/www/build/wp-includes/rest-api/endpoints/class-wp-rest-plugins-controller.php:288 /var/www/build/wp-includes/rest-api/class-wp-rest-server.php:1139 /var/www/build/wp-includes/rest-api/class-wp-rest-server.php:985 /var/www/tests/phpunit/includes/spy-rest-server.php:57 /var/www/build/wp-includes/rest-api.php:479 /var/www/tests/phpunit/tests/rest-api/rest-plugins-controller.php:379
Apparently [49913] and [49951] didn't cover the external HTTP request in plugins_api()
. Reopening for investigation.
#38
in reply to:
↑ 37
@
8 months ago
Replying to SergeyBiryukov:
Apparently [49913] and [49951] didn't cover the external HTTP request in
plugins_api()
.
Looks like the plugins_api()
call in these tests is by design, so they should probably use the external-http
group and the skipTestOnTimeout()
method.
The backports are not tied to a particular release, but the second part (plugin controller tests) needs some investigation. Moving to the next release for now.