Magento2: Running bin/magento setup:upgrade re-enables layout, block_html and full_page caches

[markshust]

Preconditions (*)

1.Magento 2.4-develop

Steps to reproduce (*)

1. Disable the caches by running: bin/magento cache:disable block_html full_page layout
2. Run: bin/magento setup:upgrade

Expected result (*)

1. After setup:upgrade completes execution, the block_html, full_page, and layout caches are still disabled

Actual result (*)

1. An "enabling caches" message appears in the CLI output of setup:upgrade:

Enabling caches:
Current status:
Array
(
    [layout] => 1
    [block_html] => 1
    [full_page] => 1
)

1. Those caches are re-enabled:

magento235$ bin/magento cache:status
Current status:
                        config: 1
                        layout: 1
                    block_html: 1
                   collections: 1
                    reflection: 1
                        db_ddl: 1
               compiled_config: 1
                           eav: 1
         customer_notification: 1
            config_integration: 1
        config_integration_api: 1
                google_product: 1
                     full_page: 1
             config_webservice: 1
                     translate: 1
                        vertex: 1

[m2-assistant[bot]]

Hi @markshust. Thank you for your report.
To help us process this issue please make sure that you provided the following information:

• [ ] Summary of the issue
• [ ] Information on your environment
• [ ] Steps to reproduce
• [ ] Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

@markshust do you confirm that you were able to reproduce the issue on vanilla Magento instance following steps to reproduce?

• [ ] yes
• [ ] no

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[chickenland]

We've just noticed this too. Came here to write a report but you beat me to it @markshust :)

[markshust]

@magento give me 2.4-develop instance

[magento-engcom-team]

Magento instance deployment temporary unavailable due to service maintenance.

[m2-assistant[bot]]

Hi @engcom-Alfa. Thank you for working on this issue.
In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 4. Verify that the issue is reproducible on 2.4-develop branch

  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and _stop verification process here_!

• [ ] 5. Add label Issue: Confirmed once verification is complete.

• [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

[markshust]

@magento give me 2.4-develop instance

[magento-engcom-team]

Magento instance deployment temporary unavailable due to service maintenance.

[engcom-Alfa]

The issue is reproducible on fresh 2.4-develop.

[magento-engcom-team]

:white_check_mark: Confirmed by @engcom-Alfa
Thank you for verifying the issue. Based on the provided information internal tickets MC-34331 were created

Issue Available: @engcom-Alfa, _You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself._

[gauravharsh15]

@magento I am working on this

[m2-assistant[bot]]

Hi @gauravharsh15! :wave:
Thank you for joining. Please accept team invitation :point_right: here :point_left: and add your comment one more time.

[gauravharsh15]

@magento I am working on this

[gauravharsh15]

Hello @markshust ,
According to current functionality, three caches(block_html, full_page, layout) are being disabled and then enabled again and if there are no cache disabled from (block_html, full_page, layout) then it disable all caches and enable all caches, please help to suggest the expected behaviour.
there must be some reason we are disabling and enabling all caches in Upgrade command.

[markshust]

The desired functionality is that whatever caches are disabled/enabled
before running the setup:upgrade command, should be re-applied after
running the command. So, the cache statuses should not change whatsoever
when running setup:upgrade.

On Sun, May 17, 2020 at 7:22 AM gauravharsh15 [e-mail]
wrote:

Hello @markshust https://github.com/markshust ,
According to current functionality, three caches(block_html, full_page,
layout) are being disabled and then enabled again and if there are no cache
disabled from (block_html, full_page, layout) then it disable all caches
and enable all caches, please help to suggest the expected behaviour.
there must be some reason we are disabling and enabling all caches in
Upgrade command.

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/magento/magento2/issues/28186#issuecomment-629781370,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AADKWJIAQH252LH2VSYAGNLRR7CGFANCNFSM4M55RXAQ
.

[gauravharsh15]

The desired functionality is that whatever caches are disabled/enabled before running the setup:upgrade command, should be re-applied after running the command. So, the cache statuses should not change whatsoever when running setup:upgrade.
…
On Sun, May 17, 2020 at 7:22 AM gauravharsh15 @.*> wrote: Hello @markshust https://github.com/markshust , According to current functionality, three caches(block_html, full_page, layout) are being disabled and then enabled again and if there are no cache disabled from (block_html, full_page, layout) then it disable all caches and enable all caches, please help to suggest the expected behaviour. there must be some reason we are disabling and enabling all caches in Upgrade command. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#28186 (comment)>, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADKWJIAQH252LH2VSYAGNLRR7CGFANCNFSM4M55RXAQ .

Thanks @markshust , can you please help to guide on these pointers as well :

1. As per current feature, we are first disabling cache[_block_html, full_page, layout_] and later enabling these cache, do we need to change it with first enabling the current disabled cache and later disabling them once the command execution is about to end ?

2. If we just want it to make it as it is then do we really need to disable/enable or update any cache ?

3. if no cache is disabled, what should be the behaviour ? should it disable or enable any cache ?

PS: Newbie here, your help would be appreciated.

[chandru-199]

PR created for this issue.
https://github.com/magento/magento2/pull/28191

[ktruehl]

In case this helps, we're using the following patch for this:

diff --git a/setup/src/Magento/Setup/Model/Installer.php b/setup/src/Magento/Setup/Model/Installer.php
index 535040f942..8aee179b5f 100644
--- a/setup/src/Magento/Setup/Model/Installer.php
+++ b/setup/src/Magento/Setup/Model/Installer.php
@@ -875,6 +875,19 @@ class Installer
             LayoutCache::TYPE_IDENTIFIER,
         ];

+// PATCH START disable/enable only enabled frontend caches during setup:upgrade
+        $cacheManager = $this->objectManagerProvider->get()->create(\Magento\Framework\App\Cache\Manager::class);
+        /* @var \Magento\Framework\App\Cache\Manager $cacheManager */
+        $status = $cacheManager->getStatus();
+        $filteredFrontendCaches = [];
+        foreach ($frontendCaches as $cache)
+        {
+            if ($status[$cache] ?? null)
+                $filteredFrontendCaches[] = $cache;
+        }
+        $frontendCaches = $filteredFrontendCaches;
+// PATCH END
+
         /** @var \Magento\Framework\Registry $registry */
         $registry = $this->objectManagerProvider->get()->get(\Magento\Framework\Registry::class);
         //For backward compatibility in install and upgrade scripts with enabled parallelization.

[VladimirZaets]

The upgrade functionality should be tested manually

[orthener]

@ktruehl Can you show how to implement this patch? I tried "by manual" but setup/src/Magento/Setup/Model/Installer.php file not changed.

[bdbosman]

I'm having the same issue on 2.3.5-p1

[magento-engcom-team]

Hi @markshust. Thank you for your report.
The issue has been fixed in magento/magento2#28491 by @AbdulRahmanAbouzaid in 2.4-develop branch
Related commit(s):

• e73e8e42375ce54f07ebeb6e94a71758edc725ad
• ec9462e200021ebc0fd24fce64a15fe51d9062cd
• d8c0afd344e28c33a58e6416535ed48090e50da4
• 3028f29cb1ac76d8dd9e87b9ac96e40f4f0fda28
• 6a82be16a1371116a92ef9dfb5e6dc09fd3bfe51
• 36198f2cbe74df6dccbf73a7b33e2961fb57eaf6
• 634d8572ee68f65229743a04d5597641a9fc55be
• dceaeae3397021535b88d8f49c040f44a3d01f93
• 46c60ea6ef3b82fdbb2bf02a250fe493e91ba454
• e3b8b3b9c78d190c3148280c47f0bebebfe62a13
• 7e4cfe2bda94350c76fe09df69e49dd1ae5e7a33
• aaf944ecc411516ec245226dcf53957351b96feb
• 461b644cb5ca91259ae3bc48e4aa740e05ed109b

The fix will be available with the upcoming 2.4.2 release.