Magento 2, ofthen a second deploy needed to work without errors

[Aquive]

trafficstars

• Deployer version: 7.3.1
• Deployment OS: Ubuntu 22.04

Very often we need to do a second deploy to make magento 2 working again after a first "succesfull" deploy. (The deploy is succesfull but Magento throws an erros, see below). I am not exactly sure when this problem occurs but I think it happens when enabling a previously disabled module.

This time it was this error. The CSP module was disabled, and with this deploy it was being enabled.

There has been an error processing your request
Warning: Undefined array key "policy_id"
in /vendor/magento/module-csp/Model/Collector/ConfigCollector.php on line 111

Deploy.php

<?php
namespace Deployer;

require 'recipe/magento2.php';

// Config

set('repository', '<repo url>');
set('update_code_strategy', 'clone');
set('writable_mode', 'chmod');
set('keep_releases', 3);

add('shared_files', []);
add('shared_dirs', [
    'pub/feeds',
    'pub/blog',
    'pub/sitemaps'
]);
add('writable_dirs', []);

// Languages
set('static_content_locales', 'nl_NL');
set('magento_themes', [
    'Aqm/Luma',
    ]);
set('magento_themes_backend', ['Magento/backend']);
set('static_deploy_options', '--no-parent');
set('static_content_locales_backend', 'en_US nl_NL');
set('split_static_deployment', true);

// Hosts
host('production')
    ->set('hostname', '<host>')
    ->set('remote_user', 'app')
    ->set('deploy_path', '<path>');

// Hooks

after('deploy:failed', 'deploy:unlock');

Upvote & Fund

• We're using Polar.sh so you can upvote and help fund this issue.
• We receive the funding once the issue is completed & confirmed by you.
• Thank you in advance for helping prioritize & fund our backlog.

[peterjaap]

Is in this case the module already in config.php as enabled or isn't it in the config.php and enables setup:upgrade it on deploy?

[Aquive]

Hey @peterjaap thanks for your fast reply. It is deployed after running/testing/commiting everything locally. So the module is present in config.php with a 1 (enabled) like below.

'Magento_Csp' => 1,

This is just an example. We experience sometimes a second deploy is needed. I am not sure if it is allways when enabling a module. It might be the case in other situations too. I will pay attention and check it from now on.

[LouisdeLooze]

Hi @Aquive, No idea if you still have this issue, but I had similar issues (more specifically about missing classes). I fixed it by using rotating cache prefixes, as explained here. Hope this helps!

[Aquive]

I didn't came accross it too often lately, but it is good to know there is a possible solution. I will test it out when I encounter it again.

Btw, any idea why this is not default? Does it come at a cost?

[github-actions[bot]]

This issue has been automatically closed. Please, open a discussion for bug reports and feature requests.

Read more: [https://github.com/deployphp/deployer/discussions/3888]

[github-actions[bot]]

This issue has been automatically closed. Please, open a discussion for bug reports and feature requests.

Read more: [https://github.com/deployphp/deployer/discussions/3888]

[JithinTerrificminds]

We're encountering the same issue in our production environment every midnight. Has anyone found a solution or identified the root cause?

The issue can be replicated by renaming/commenting the file : vendor/magento/module-csp/etc/config.xml

Also the issue seems to be only happening on a scalable server.

[JithinTerrificminds]

It appears we have found the cause of this issue, Hope this helps.

The issue happens as the old cron are not getting removed only new cron are getting added.

you can confirm this by command : crontab -l

The old cron are still pointing to the older releases and thus adding removed cron to the cron list.

The issue can only be replicated if the environment has redis configured.

[peterjaap]

I would advise you to change your crons to use the current symlink and leave them in place.

[Aquive]

@JithinTerrificminds I don't think cron has anything to with this to be honest. If you have trouble with that, just link to the current symlink of your deployment, like Peter Jaap said.

The actual issue here is the order of actions which are taken while deploying, without artifact deployment does the system go to a state where it throws errors. I am not sure what the actual issue is. Deploying a second time does solve this specific issue.

[JithinTerrificminds]

Thanks @peterjaap @Aquive

We just added an before to remove the cron before adding the new cron :

before('magento:upgrade:db', 'magento:cron:stop'); after('magento:upgrade:db', 'magento:cron:install');

[Aquive]

@JithinTerrificminds there is no need to do this. How did you come up with this?

Just change it to something like this below. Notice the current dir? This always points to the deployed version, so it does always resolve to production deploy.

* * * * * /usr/bin/php8.1 /data/web/production/current/bin/magento cron:run

[JithinTerrificminds]

I am not sure if's correct but we do stop the cron just before setup upgrade to avoid some issues.

We do also have something like this :

after('magento:maintenance:enable-if-needed', 'magento:cron:stop');