Hard failure after module install if composer is not found

Doesn't this relate to 🐛 [upstream] Handle "Composer not found" error better in ComposerExecutableValidator Needs work and 📌 Create an API for base requirement validators which run before other validators and stop event propagation if they fail Fixed ? What is the correct implementation order?

The latest release for Composer stager fixes the problem where the backtrace for the error was incorrect https://github.com/php-tuf/composer-stager/releases/tag/v1.2.1

Updating the summary here with solution.

I think 📌 Create an API for base requirement validators which run before other validators and stop event propagation if they fail Fixed is tricky and we should not wait for that one but yes related

Attempting to make the title understandable.

I have added the proposed resolution but can't test it as I am unable to reproduce the scenario locally. Also I think we should have a test for this scenario.

At minimum, I think you can simulate this by providing a stub implementation of \PhpTuf\ComposerStager\Infrastructure\Service\Finder\ExecutableFinderInterface which throws the same exception as was reported above. Hell, you could even swap out the Drupal\package_manager\ExecutableFinder service with yours, and then you can easily test it?

Also, the changes you made are in ComposerMinimumStabilityValidator and ComposerPluginsValidator. Why? The stack trace clearly shows that it's ComposerExecutableValidator that's triggering this exception (by calling \Drupal\package_manager\ExecutableFinder), so I do not understand why we'd change any other validator?

I just implemented the proposed resolution which requires changes in ComposerMinimumStabilityValidator and ComposerPluginsValidator. And also in summary we have I think the error might be coming from another validator other than ComposerExecutableValidator but there is cache in composer-stager that causes the wrong backtrace to show up.... so that's may be the reason why we need changes in ComposerMinimumStabilityValidator and ComposerPluginsValidator.

So, I tried to test it locally and I get hard failure

The website encountered an unexpected error. Please try again later.

PhpTuf\ComposerStager\Domain\Exception\LogicException: The "composer" executable cannot be found. Make sure it's installed and in the $PATH. in Drupal\package_manager\ExecutableFinder->find() (line 54 of modules/contrib/automatic_updates/package_manager/src/ExecutableFinder.php).
PhpTuf\ComposerStager\Infrastructure\Service\ProcessRunner\AbstractRunner->findExecutable() (Line: 51)
PhpTuf\ComposerStager\Infrastructure\Service\ProcessRunner\AbstractRunner->run(Array, Object) (Line: 87)
Drupal\package_manager\ComposerInspector->getConfig('allow-plugins', '/Users/kunal.sachdev/www/ten_zero') (Line: 177)
Drupal\package_manager\Validator\ComposerPluginsValidator->validateStagePreOperation(Object, 'Drupal\package_manager\Event\StatusCheckEvent', Object)
call_user_func(Array, Object, 'Drupal\package_manager\Event\StatusCheckEvent', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object) (Line: 49)
Drupal\automatic_updates\Form\UpdateFormBase->runStatusCheck(Object, Object, 1) (Line: 204)
Drupal\automatic_updates\Form\UpdaterForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 534)
Drupal\Core\Form\FormBuilder->retrieveForm('automatic_updates_updater_form', Object) (Line: 281)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 163)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 74)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 681)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

and if I apply the fix we are doing here in ComposerPluginsValidator then I don't get a hard failure.

#12:

I think the error might be coming from another validator other than ComposerExecutableValidator but there is cache in composer-stager that causes the wrong backtrace to show up..

Aha!

But that was fixed in https://github.com/php-tuf/composer-stager/releases/tag/v1.2.1! So rather than modifying other validators, we should just bump our version requirement 😊

#13: Great that you were able to reproduce this! What version of php-tuf/composer-stager did you test that with? I bet (and hope!) that it was 1.2.0.

Next step: update to 1.2.1 and verify that that fixed the problem.

So, I just checked and I am using 1.2.1 version of php-tuf/composer-stager and yes it fixes the cache problem and the back trace which I get is correct now i.e

The website encountered an unexpected error. Please try again later.

PhpTuf\ComposerStager\Domain\Exception\LogicException: The "composer" executable cannot be found. Make sure it's installed and in the $PATH. in Drupal\package_manager\ExecutableFinder->find() (line 54 of modules/contrib/automatic_updates/package_manager/src/ExecutableFinder.php).
PhpTuf\ComposerStager\Infrastructure\Service\ProcessRunner\AbstractRunner->findExecutable() (Line: 51)
PhpTuf\ComposerStager\Infrastructure\Service\ProcessRunner\AbstractRunner->run(Array, Object) (Line: 87)
Drupal\package_manager\ComposerInspector->getConfig('allow-plugins', '/Users/kunal.sachdev/www/ten_zero') (Line: 177)
Drupal\package_manager\Validator\ComposerPluginsValidator->validateStagePreOperation(Object, 'Drupal\package_manager\Event\StatusCheckEvent', Object)
call_user_func(Array, Object, 'Drupal\package_manager\Event\StatusCheckEvent', Object) (Line: 111)
Drupal\Component\EventDispatcher\ContainerAwareEventDispatcher->dispatch(Object) (Line: 49)
Drupal\automatic_updates\Form\UpdateFormBase->runStatusCheck(Object, Object, 1) (Line: 204)
Drupal\automatic_updates\Form\UpdaterForm->buildForm(Array, Object)
call_user_func_array(Array, Array) (Line: 534)
Drupal\Core\Form\FormBuilder->retrieveForm('automatic_updates_updater_form', Object) (Line: 281)
Drupal\Core\Form\FormBuilder->buildForm(Object, Object) (Line: 73)
Drupal\Core\Controller\FormController->getContentResult(Object, Object)
call_user_func_array(Array, Array) (Line: 123)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 580)
Drupal\Core\Render\Renderer->executeInRenderContext(Object, Object) (Line: 124)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->wrapControllerExecutionInRenderContext(Array, Array) (Line: 97)
Drupal\Core\EventSubscriber\EarlyRenderingControllerWrapperSubscriber->Drupal\Core\EventSubscriber\{closure}() (Line: 163)
Symfony\Component\HttpKernel\HttpKernel->handleRaw(Object, 1) (Line: 74)
Symfony\Component\HttpKernel\HttpKernel->handle(Object, 1, 1) (Line: 58)
Drupal\Core\StackMiddleware\Session->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\KernelPreHandle->handle(Object, 1, 1) (Line: 106)
Drupal\page_cache\StackMiddleware\PageCache->pass(Object, 1, 1) (Line: 85)
Drupal\page_cache\StackMiddleware\PageCache->handle(Object, 1, 1) (Line: 48)
Drupal\Core\StackMiddleware\ReverseProxyMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\NegotiationMiddleware->handle(Object, 1, 1) (Line: 51)
Drupal\Core\StackMiddleware\StackedHttpKernel->handle(Object, 1, 1) (Line: 681)
Drupal\Core\DrupalKernel->handle(Object) (Line: 19)

but we still need changes in ComposerPluginsValidator which solves this problem of hard failure.

Discussed in detail with @kunal.sachdev.

The stack trace still clearly shows that ComposerPluginsValidator is triggering the LogicException. That is the problem!

We need to make sure that ComposerExecutableValidator runs before all other validators that interact with composer (through ComposerInspector). That means we need to update \Drupal\package_manager\Validator\ComposerExecutableValidator::getSubscribedEvents() to make these callbacks have the highest possible priority and stop propagation!

(Otherwise every single other validator would have to worry about this.)

Ironically, that means this issue is now hard-blocked on 📌 Create an API for base requirement validators which run before other validators and stop event propagation if they fail Fixed — thanks @kunal.sachdev for pointing that out!

I think that
#3312960-37: Certain validators should be higher priority and stop further validation →
plus
📌 ComposerInspector::validate() should run `composer validate` Fixed

would entirely solve this?

📌 ComposerInspector::validate() should run `composer validate` Fixed is in, 📌 Create an API for base requirement validators which run before other validators and stop event propagation if they fail Fixed is close.

Discussed with @tedbow. Conclusion: do manual testing after 📌 Create an API for base requirement validators which run before other validators and stop event propagation if they fail Fixed is committed 👍

📌 Create an API for base requirement validators which run before other validators and stop event propagation if they fail Fixed is fixed.

Haha you beat me to it, @kunal.sachdev! Looking forward to reading your findings!

I tested it again with Automatic Updates 3.0.x and the module was installed successfully on the site with no hard failure. Then, I checked the status report page which is