[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