Currently if Composer Stager has runtime error during commit(our apply) we would inform the user because we display exceptions through the batch form process and log errors in cron. But things become unpredictable even after a successful update, see #3291147: Successfully applying an update puts the remainder of the request into an unreliable state → , so we can assume unsuccessful update would be even more unpredictable. We couldn't be sure how much of the update actually applied before the error.
If there is error in the committer the site may say it has been updated because Drupal.php which has the version number may have been updated but other files may not have been copied over, say a php file that actually has a security fix.
Further more besides the committer throwing an exception there may be a hard failure in the committer that doesn't return or more likely the logging system might not work in the same request after a partial update(even a full update) so there is no guarantee any exception would be logged.
core/lib/README.txt unwritableYou will get an error but the site will say has been updated to 9.3.16. There will be no indication afters that update did not apply correctly. Even though the error was because of README.txt there is no way of knowing which files that would of been updated/deleted after that file were not updated/deleted
Probably multiple step.
\PhpTuf\ComposerStager\Domain\Core\Committer\CommitterInterface::commit says
*
* @throws \PhpTuf\ComposerStager\Domain\Exception\InvalidArgumentException
* If $exclusions includes invalid paths.
* @throws \PhpTuf\ComposerStager\Domain\Exception\PreconditionException
* If the preconditions are unfulfilled.
* @throws \PhpTuf\ComposerStager\Domain\Exception\RuntimeException
* If the operation fails.If the exception is InvalidArgumentException or PreconditionException we can probably safely assume the commit did not even start. With any other exception it is probably safest to assume that the site may be in a half updated state and should restored from back up.
The above solution requires an exception to actually be caught. in the rare case where there is fatal which happens in commit the exception does not come back should also assume the site is half updated. Right now the site would just say there is an existing update that you could delete. it may or may not show the site has been updated depending on which files were copied.
To handle this problem we should write a PACKAGE_MANAGER_UPDATE_FAILURE.txt to the active directory and delete this file as soon as commit comes back from Composer stager. We should always check for existence of this fail and tell the site admin to restore from backup.
In follow up issue we could do the full version of 📌 Create a manual fallback recovery system if update fails during the Apply phase Active
Fixed
2.0
Code
Not all content is available!
It's likely this issue predates Contrib.social: some issue and comment data are missing.
Question about this: this issue was about the committer, but was a similar solution applied for the beginner? For example, if the PHP script is terminated halfway through copying from active to stage, how do we know that that happened and recover from it?
Also, do we have test coverage for these scenarios (PHP script termination during the copy from active to stage or from stage to active), and is so, where are those tests?