Cached data from current release causes new release to fail with redis caching

[PascalBrouwers]

Cached data from current release causes new release to fail with redis caching

[PascalBrouwers]

That's not possible, but I should make sure that running commands between release_path and current_path the cache should be flushed.

[zetxek]

We have also experienced this. But we have seen that capistrano-magento2 in the end just invokes magento:setup:di:compile, so it didn't look like the element to blame:

capistrano-magento2/lib/capistrano/tasks/deploy.rake

Line 57 in 3d32c7d

invoke 'magento:setup:di:compile'

We still have some issues in our production environment during production releases - where classes are not generated.
But seeing your issue @PascalBrouwers made us thought of it to tackle it better than manually copying the generated files from the staging server to production 😅

Maybe capistrano-magento2 could force Magento to ignore the Redis cache while preparing the 2nd release?

[PascalBrouwers]

Small update: you also need to fix the autoloader because that is cached too. So run this too:
invoke!('magento:composer:install') if fetch(:magento_deploy_composer)

[PascalBrouwers]

Trying to get a fail-safe method for this but it feels like there isn't one.

As soon as you flush the redis cache there is the possibility that a visitor is on the site and trigger the redis cache for the current release, while you were trying to fill it with the release_path.
There is the option to set the maintenance flag, but that would mean a long downtime.

[PascalBrouwers]

Also an issue when running php 7.2 / 7.3 in your current release and the latest release need php 7.4
Running composer install in both directories isn't going to work with the same php version.

[PascalBrouwers]

Decided to go with using a different cache prefix for each deployment. This way generated files and other caches don't interfere with each other during a deploy for a site that has allot of visitors. Because this runs before composer, if also fixes the issue with the classmap cache.

after "deploy:symlink:linked_files", "set_cache_prefix"
task :set_cache_prefix do
  on release_roles :all do
    within release_path do
      unless test %Q[#{SSHKit.config.command_map[:php]} -r '
          $cfg = include "#{shared_path}/app/etc/env.php";
          exit((int)!isset($cfg["cache"]["frontend"]["default"]["id_prefix"]));
        ']
        # generate a new prefix
        version = '100_'
      else
        # get the current prefix
        version = capture %Q[#{SSHKit.config.command_map[:php]} -r '
            $cfg = include "#{shared_path}/app/etc/env.php";
            echo(($cfg["cache"]["frontend"]["default"]["id_prefix"]));
        ']
      end

      # convert prefix to a number and increment it
      version = version.gsub("_", "")
      versionNumber = version.to_i
      newVersionNumber = versionNumber + 1
      set :newVersionNumber, newVersionNumber

      # copy the file as a normal file in the next release
      execute :rm, "-rf #{release_path}/app/etc/env.php"
      execute :cp, "-rf #{shared_path}/app/etc/env.php #{release_path}/app/etc/env.php"

      execute %Q[#{SSHKit.config.command_map[:php]} -r '
        $cfg = include "#{release_path}/app/etc/env.php";
        $cfg["cache"]["frontend"]["default"]["id_prefix"] = "#{fetch(:newVersionNumber)}_";
        $out = "<?php return " . var_export($cfg, true) . ";"
        file_put_contents("#{release_path}/app/etc/env.php", $out);
        ']

      # save new env file to shared dir
      execute :rm, "-rf #{shared_path}/app/etc/env.php"
      execute :cp, "-rf #{release_path}/app/etc/env.php #{shared_path}/app/etc/env.php"
    end
  end
end

Works when env.php does not have a cache prefix yet. Also Magento fixes the array( syntax with a short syntax [ during deployment by itself.
@davidalger is this an idea to include it?