Magento 2 Recipe: Fix import needed after deployment failure during upgrade #4180

[carlos-reynosa]

Pull request to ensure that if the magento deployment fails and the release is reverted the configuration is properly imported. Deployments mail fail during upgrade and after new configuration has been imported.

1. Added deploy:magento:failed task to group post deployment failure tasks for magento 2
2. Ensure to check config status and import configuration if deployment reverts and fails.

• [ x] Bug fix #…?
• [ x] New feature?
• BC breaks?
• Tests added?
• Docs added?

Fixes #4180

  Please, regenerate docs by running next command:
  $ php bin/docgen

[Copilot]

Pull request overview

Adds a dedicated Magento 2 post-failure hook so that additional recovery steps (config import + maintenance disable) run when a deployment fails—intended to keep Magento configuration consistent after a failed upgrade/deploy attempt.

Changes:

• Replaces the direct magento:maintenance:disable failure hook with a new grouped task deploy:magento:failed.
• Adds deploy:magento:failed task to run magento:config:import and then disable maintenance mode.
• Regenerates Magento 2 recipe documentation to include the new task and updated source line references.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.

File	Description
recipe/magento2.php	Introduces deploy:magento:failed and wires it to deploy:failed for Magento-specific recovery steps.
docs/recipe/magento2.md	Updates autogenerated docs to reflect the new task and shifted source line numbers.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[carlos-reynosa]

This update fixes Magento config import behavior after failed deployments.

-Added a dedicated current-release config check and import flow for failure scenarios.
-Updated the failure handler to run config import against the live (last successful) release instead of the failed release.
-Added a warning note to avoid using bin/magento in deploy:failed handlers because it can resolve to the failed release.
-Included a small cleanup from the previous commit by removing an outdated duplicate comment.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

Comments suppressed due to low confidence (1)

recipe/magento2.php:347

• magento:config:import:on-current directly runs bin/magento from {{current_path}} without the directory-exists guard used by the maintenance tasks. In failure scenarios (especially first deploy), this can throw and abort subsequent failure handling. Consider adding the same if [ -d {{current_path}} ] guard and/or catching RunException so this task becomes a no-op when there is no live release to import from.

desc('Config Import on current release');
task('magento:config:import:on-current', function () {
    if (get('config_import_needed_on_current')) {
        // do not use {{bin/magento}} as it must run on the current (last successful) release in failure scenarios
        run('{{bin/php}} {{current_path}}/{{magento_dir}}/bin/magento app:config:import --no-interaction');
    } else {
        writeln('App config is up to date => import skipped');
    }
});

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

recipe/magento2.php:359

• magento:config:import:on-current only catches RunException, but run() can throw TimeoutException or other non-Run exceptions. If that happens, this task will fail and (because deploy:magento:failed is a group task) magento:maintenance:disable may never run, potentially leaving the site in maintenance mode after a failed deploy. Consider catching \Throwable (or TimeoutException + RunException) and swallowing it here since this is a best-effort failure hook.

desc('Config Import on current release');
task('magento:config:import:on-current', function () {
    try {
        if (get('config_import_needed_on_current')) {
            // do not use {{bin/magento}} as it must run on the current (last successful) release in failure scenarios
            run('{{bin/php}} {{current_path}}/{{magento_dir}}/bin/magento app:config:import --no-interaction');
        } else {
            writeln('App config import skipped');
        }
    } catch (RunException $e) {
        writeln('Unable to import app config on current release => import skipped');
    }
});

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (1)

recipe/magento2.php:354

• magento:config:import:on-current runs app:config:import using the global default_timeout. If users set a very large default_timeout and the import hangs, deploy:failed can be blocked for a long time and delay recovery (including disabling maintenance mode). Consider passing an explicit timeout/idleTimeout for this command so the failure handler stays best-effort and bounded.

        if (get('config_import_needed_on_current')) {
            // do not use {{bin/magento}} as it must run on the current (last successful) release in failure scenarios
            run('{{bin/php}} {{current_path}}/{{magento_dir}}/bin/magento app:config:import --no-interaction');
        } else {
            writeln('App config import skipped');

[carlos-reynosa]

Probably overkill unless we start adding it to every run command. I suggest not.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated no new comments.