- Issue created by @wim leers
- Open on Drupal.org βCore: 10.1.x + Environment: PHP 8.1 & MySQL 8last update
over 1 year ago Not currently mergeable. - @wim-leers opened merge request.
- Assigned to wim leers
- Status changed to Needs work
over 1 year ago 2:39pm 3 May 2023 - last update
over 1 year ago 765 pass - π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
The commit I just pushed works in manual testing, but the automated test is very difficult to write. Will probably only finish that tomorrow.
- last update
over 1 year ago 297 pass, 109 fail - Issue was unassigned.
- Status changed to Needs review
over 1 year ago 4:17pm 3 May 2023 - π§πͺBelgium wim leers Ghent π§πͺπͺπΊ
Pushed what I got so far that AFAICT proves writing a
Kernel
test for this is impossible.Maybe I can write a functional test for this, but I've not been very successful so far π«
Marking for the first commit.
- Assigned to tedbow
- last update
over 1 year ago 301 pass, 111 fail - πΊπΈUnited States tedbow Ithaca, NY, USA
I don't think we want to use Failure marker for this. The class doc states
* The failure marker is a file placed in the active directory while staged * code is copied back into it, and then removed afterwards. This allows us to * know if a commit operation failed midway through, which could leave the site * code base in an indeterminate state -- which, in the worst case scenario, * might render Drupal being unable to boot.
So this is for a very particular purpose, "commit operation failed midway through, which could leave the site
* code base in an indeterminate state". I created π Document what the existence of the PACKAGE_MANAGER_FAILURE.yml means Fixed to make this clearerI don't we should reuse it for this. We stop all operations if this file exists. The purpose of this file is that you can't trust your site's code at that point.
Of the 5 places we use this only during Apply would it leave your site's code base in an indeterminate state. But since it added to the first line of
\Drupal\package_manager\StageBase::apply
for all we know the time out is from very badly written PreApplyEvent subscriber. In that case we should not write the marker file. InStageBase::apply
if call$this->committer->commit($stage_dir, $active_dir, $paths_to_exclude, NULL, $timeout);
and we never return we will have already written the marker file and it will not be delete if the execution does not return toStageBase::apply
. In that case still think we want to totally replace the file though inlogExecutionTimeFailure
as this MR does because it currently doesn't mention anything about restoring your site from a backup like\Drupal\package_manager\StageBase::getFailureMarkerMessage()
.I will make some more specific suggestions in the MR
- Status changed to Needs work
over 1 year ago 1:59am 16 May 2023 - πΊπΈUnited States tedbow Ithaca, NY, USA
@Wim Leers can you update the summary to state concisely what the problem is we are trying to address. The Problem/Motivation section currently just links to another issue comment and that issue comment then mentions the 1 above it and then links to yet issue
- Status changed to Postponed: needs info
over 1 year ago 2:00am 16 May 2023 - Assigned to wim leers