[wp-trac] [WordPress Trac] #54546: Fatal error receive while updating WP 5.8.2 to WP 5.9.

[WordPress Trac]

#54546: Fatal error receive while updating WP 5.8.2 to WP 5.9.
---------------------------------------+---------------------
 Reporter:  apeksha10                  |       Owner:  (none)
     Type:  defect (bug)               |      Status:  new
 Priority:  normal                     |   Milestone:  5.9
Component:  Upgrade/Install            |     Version:  trunk
 Severity:  normal                     |  Resolution:
 Keywords:  needs-patch needs-testing  |     Focuses:
---------------------------------------+---------------------

Comment (by costdev):

 == Update on Fatal Error
 === The Cause

 - The `Requests_Exception` class isn't loaded into memory prior to the
 upgrade running.
 - When Requests 2.0 is downloaded and copied, it overwrites the contents
 of `wp-includes/Requests/Exception.php` with a namespaced
 `WpOrg\Requests\Exception` class.
 - When the database upgrade is called and
 `Requests_Transport_cURL->process_response()` results in a cURL timeout,
 it tries to throw `Requests_Exception`. Fatal.

 === The Solution
 We can resolve this fatal by including the following line at the top of
 `wp-admin/includes/update-core.php` ''in the upgrade package'':

 {{{#!php
 <?php

 require_once ABSPATH . 'wp-includes/Requests/Exception.php';

 }}}

 === Why?
 - `Requests_Exception` is used before Requests 2.0.
 - `WpOrg\Requests\Exception` is used after Requests 2.0.
 - Both use the same file.
 - The exception class for the current Requests library used by the site
 needs to be loaded into memory ''before'' the upgrade process begins.

 === What else do we need to do?
 - Update every upgrade package on wp.org for WordPress versions that use
 Requests.
 - This has been confirmed as needed for earlier WordPress versions.
 - Adding this fix to an earlier upgrade package before rolling back has
 been confirmed as working by myself and @mkaz.
 - This means that we don't have to force a maintenance update on existing
 installs. When they try to upgrade or rollback, the package will have what
 they need.

 ----

 == Update on cURL timeout
 === The Cause
 - This appears to be an issue contacting wordpress.org or with Apache.
 - Props to @pbiron for reporting this timeout during testing:

 {{{
 PHP Warning:  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.)
 }}}
 - The timeout also occurred on Apache for me.
 - The timeout doesn't happen every time.
 - This doesn't occur on NGINX for me or for @mkaz.

 === The Solution
 - Technically, if a timeout occurs, it ''should'' throw the above warning.
 - @pbiron notes that increasing the timeout for the Requests library has
 proven useful for avoiding timeouts. However, this timeout should not be
 happening in the first place. The default timeout is 60 seconds to contact
 wp.org.
 - Resolving the timeout requires more investigation.

 === Why?
 - The timeout, at least in some cases, occurs at the "Upgrading
 Database..." step.
 - I haven't looked into whether or not the database gets upgraded before
 this fails.
 - The timeout, at least in some cases, causes the updater lock to remain
 in place, blocking repeat updates without deleting the entry in the
 database.

 === What else do we need to do?
 - Investigate the cause of this particular timeout.
 - Determine whether it is only occurring on Windows with Apache.
 - Explore a solution.
 - Test.

 Huge props to @pbiron and @mkaz for helping to test this fix.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/54546#comment:27>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform