Skip to content

Comments

Fix incorrect handling of promises during package reset#124

Merged
jooname merged 4 commits intomasterfrom
fix/incorrect-handling-of-promises-during-package-reset
Jul 18, 2025
Merged

Fix incorrect handling of promises during package reset#124
jooname merged 4 commits intomasterfrom
fix/incorrect-handling-of-promises-during-package-reset

Conversation

@jooname
Copy link
Contributor

@jooname jooname commented May 27, 2025

Alternative solution to #119, related to issue #118

Main difference is that in processReinstallOperation instead of passing Composer instance through couple of other classes to allow calling Composer\Util\SyncHelper::downloadAndInstallPackageSync, we use React\Promise\all to combine handling of uninstall and download promises and once that combined promise finishes, then we handle the install promise. I did try out simply chaining the promises, but even that way it seems like first two promises are the only ones that get processed before patching. Now when the first two are combined, the installation promise happens before patching.

The solution in #119 also works, but I'm a bit hesitant to modify the public method parameters to pass additional information, especially when there is already quite a few parameters in the methods and the information needs to be passed through other classes as well. Ideally this would probably be refactored to combine all the parameters to some command/payload object, but I wouldn't go too crazy here.

I also simplified validating the promises, since at least I had issues getting the instanceof based check working. In couple of projects I tested this change with, the promise instance was something else that didn't pass the check, even when I tried out with promise interface. This simplified check should be fine, since according to the Composer code the method calls should return either null or promise instance.

…ng is achieved but without needing to pass Composer instance through different function parameters, should solve #118
throw new OperationFailure(sprintf('Download of %s failed', $package->getName()));
}

$promise = \React\Promise\all([$uninstallPromise, $downloadPromise]);

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wouldn't this still allow for $downloadPromise to complete before $uninstallPromise does? Personally I would make both promises resolve sequentially before moving on to the next step.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Correct, although I'm not seeing this as a problem since these two should be independent processes from each other, while installation depends on download and uninstallation having happened first. I could still investigate if this can be an issue though.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Confirmed, the order of download and uninstallation doesn't appear to matter. The uninstall only applies to the installed package, the download of the package is done to a different folder. So the two can be executed in any order and even in parallel.

@jooname jooname mentioned this pull request Jul 14, 2025
@jooname jooname merged commit 724be3a into master Jul 18, 2025
10 of 20 checks passed
@jooname jooname deleted the fix/incorrect-handling-of-promises-during-package-reset branch July 18, 2025 11:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants