Broken composer.lock after aborting command

[paveq]

Broken lock file without feedback when composer hangs/is killed in middle of process.

Pre-requisites

1. Have clean project without patches applied

To Reproduce Steps to reproduce the behavior:

1. Run eg. composer update for a random package
2. Abort execution at some point using (ctrl-c) At least during "Processing patches configuration" step this has happened.

Expected Composer.lock does not contain "applied_patches"

Actual

patches_applied objects are applied to lock file, and (likely) accidentally committed to VCS:

                 "php": "~7.1.3||~7.2.0"
             },
             "type": "magento2-module",
+            "extra": {
+                "patches_applied": {
+                    "vaimo/patches-magento::::src/Magento_Deploy/fix-verbosity-to-affect-compilation-errors-reporting/version-100.2.0.patch": "Fix: verbosity to affect compilation errors to aid developer with extra information, md5:dd89217197b797738e8f39d52155fe29"
+                }
+            },
             "autoload": {
                 "files": [
                     "cli_commands.php",

Notes When patches_applied is accidentally committed to lock file, it causes patches not being applied during build process, when composer thinks they are already applied.

[allanpaiste]

There isn't much you can do in that situation. We can't (as long as I know) directly trap the Ctrl+C. The thing is that patch apply is triggered when lock has been written - when all packages have been installed.

The lock contents are based on installed.json which this plugin DOES use as storage for the state of the packages in terms of what patches are applied.

On that note - the actual problem roots from the fact that installed.json is used for storing the state of a package in terms of what patches are applied which probably needs to be changed to be based on storing certain file to the root folder of the package (for example) which would also cause a patches reset to be perceived to take in place when the package is reinstalled (meaning: the file that lists applied patches is suddenly gone).

In its current state, calling an abort would mean that people have to make sure that they either re-run the call or do a lock rollback.

Alternative to all this: we could think about start hooking up to some other event other than before-autoload-dump which is when the patches are currently applied (which is AFTER the lock is written).

There might be some other event available which falls between lock write and the moment when all packages have been installed (and we do require all packages to be in place to assess the project state correctly).

Will take a look on which route to take (if you have not already).

For now: aborting out of the process like that can indeed lead to lock having an odd state (which would require user to do a composer patch:redo call).

Potential steps:

• see if there's better event to hook into that would fall between (packages installed) and (lock to be written)
• see if we can somehow trap Ctrl+C
• see if we can somehow warn user on potential side-effects when they abort
• see if we should move away from installed.json to some other state storage method that does not come with side-effects (like the fact that stuff ends up in the lock).
• see if we could start applying patches as virtual packages (thus still using installed/lock but in a more non-intrusive way).

[v-r]

we can intercept ctrl-c

<?php

declare(ticks=1);

function signalHandler($signo)
{
    echo "Warning: interrupt received" . PHP_EOL;
    exit();
}

pcntl_signal(SIGINT, 'signalHandler');

while (true) {
    echo "working\n";
    sleep(2);
}

but process can die by some other reason.

[allanpaiste]

Ah! @v-r strikes again! :) Yeah, true. There are several other ways the execution can backfire (a'la memory depletion errors, etc) so yeah. So - have to take some other route.