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

WordPress Trac noreply at wordpress.org
Wed Dec 1 21:10:18 UTC 2021

#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:  reporter-feedback  |     Focuses:

Comment (by jrf):

 Thanks @hellofromTonya and @costdev for your investigation efforts so far!

 How I read it, there are two (three) separate, distinct issues in play
 (previously undiscovered bugs), which just happen to both be triggered
 during this update:

 **1. The upgrade process does not isolate itself enough from the files
 being updated.**

 What I mean by that is, that any essential WP Core files (potentially)
 being used during the upgrade, should be loaded into memory (`require`-d)
 prior to the update starting.

 This is clearly not happening as otherwise, the Fatal for the
 `Requests_Exception` would not be thrown, which means that you could end
 up with a mix of "old" and "new" files being used during an upgrade, which
 can cause race conditions.

 For the majority of code in Core, this will not happen, as files are hard
 `require`-d and not being lazily autoloaded. But for external
 dependencies, like Requests, where an autoloader is used, this is a
 realistic risk and should be mitigated.

 While the "new" upgrader code should always be used, the rest of the files
 should be consistently from the "old" codebase.

 To fix this, some investigation would be needed to figure out exactly
 which files/parts of Core are used during the upgrade.
 Once this is known, any files on that list which depend on an autoloader,
 should be hard-required.
 A `DirectoryIterator` with `require_once` statements for those parts of
 Core, could probably solve this in a future-proof way.

 **2. The upgrade process is not designed to handle file renames involving
 only the file/directory casing.**

 Whether or not this causes problems will highly depend on the OS and
 whether or not the file-system is case-sensitive.

 To solve this, it could be considered to `unlink` old files and then move
 the new files in place, instead of plain moving the files (replacing the
 original files).

 I'm by no means saying that these are ''the'' solutions to use. Just
 pointing out some solution ''directions'' to explore.

 Once these two issues are solved, we can start to try and figure out why
 the Curl timeout is happening.... (problem three)

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

More information about the wp-trac mailing list