[Issue] Stop flushing fpc when not asked for

[m2-assistant]

This issue is automatically created based on existing pull request: #38215: Stop flushing fpc when not asked for

---

Description (*)

We found out by surprise today on Slack (thanks @benjamin-volle & @robinero) that running bin/magento cache:clean or bin/magento cache:flush will always flush FPC (built-in or Varnish) entirely, even if you've only provided a type to be cleaned like config, layout, ...

I understand that yes, probably if one of those types get flushed, you'll most likely want to flush FPC as well, but let that be up to the user to decide by seeing if they provided the type full_page explicitly in the command.

This fixes this.

Some history of this problem, flushing FPC via CLI got introduced at the request of #2025 and got fixed by c75c203

This PR enhances this a bit and will only dispatch those 2 events when either no types were provided in the command line or when full_page is one of the types provided.

Related Pull Requests

Fixed Issues (if relevant)

No idea

Manual testing scenarios (*)

1. Modify this code like so:

diff --git a/app/code/Magento/CacheInvalidate/Observer/FlushAllCacheObserver.php b/app/code/Magento/CacheInvalidate/Observer/FlushAllCacheObserver.php
index 574263ca1ee..1db01887467 100644
--- a/app/code/Magento/CacheInvalidate/Observer/FlushAllCacheObserver.php
+++ b/app/code/Magento/CacheInvalidate/Observer/FlushAllCacheObserver.php
@@ -45,6 +45,8 @@ class FlushAllCacheObserver implements ObserverInterface
      */
     public function execute(\Magento\Framework\Event\Observer $observer)
     {
+        die(sprintf("Flusing FPC in %s\n", $this::class));
+
         if ($this->config->getType() == \Magento\PageCache\Model\Config::VARNISH && $this->config->isEnabled()) {
             $this->purgeCache->sendPurgeRequest(['.*']);
         }
diff --git a/app/code/Magento/PageCache/Observer/FlushAllCache.php b/app/code/Magento/PageCache/Observer/FlushAllCache.php
index 6bcfd0e38df..d7684e25d4c 100644
--- a/app/code/Magento/PageCache/Observer/FlushAllCache.php
+++ b/app/code/Magento/PageCache/Observer/FlushAllCache.php
@@ -62,6 +62,8 @@ class FlushAllCache implements ObserverInterface
      */
     public function execute(Observer $observer)
     {
+        die(sprintf("Flushing FPC in %s\n", $this::class));
+
         if ($this->_config->getType() === Config::BUILT_IN) {
             $this->fullPageCache->clean();
         }

2. Use built-in FPC
3. Run bin/magento cache:flush and bin/magento cache:clean => expected to hit one of those die statements introduced in step 1
4. Run bin/magento cache:flush full_page and bin/magento cache:clean full_page => expected to hit one of those die statements introduced in step 1
5. Run bin/magento cache:flush layout and bin/magento cache:clean layout => expected to not hit one of those die statements introduced in step 1
6. Configure FPC to use Varnish
7. Run steps 3 to 5 again

Questions or comments

Since we introduced Magento\PageCache in the Magento_Backend module, should we add magento/module-page-cache as dependency in the Backend module's composer.json file? We can also choose to hardcode full_page and don't use the constant, that's also an option ...
Update: looks like the automated tests also picked this up, I already force-pushed a change to have it hardcoded instead of using a constant from another module, adding a dependency might be out of scope here.

I noticed that the New Relic module also listens for that adminhtml_cache_flush_system event, but it's done in the adminhtml/events.xml file, so that should be fine since it's in the adminhtml area. Running those cli commands wouldn't have triggered this observer anyways. So no regression there.

Contribution checklist (*)

• Pull request has a meaningful description of its purpose
• All commits are accompanied by meaningful commit messages
• All new or changed code is covered with unit/integration tests (if applicable)
• README.md files for modified modules are updated and included in the pull request if any README.md predefined sections require an update
• All automated tests passed successfully (all builds are green)

[m2-assistant]

Hi @engcom-Hotel. 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: 👇

• 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
• 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
• 3. Add Area: XXXXX label to the ticket, indicating the functional areas 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.

[github-jira-sync-bot]

✅ Jira issue https://jira.corp.adobe.com/browse/AC-10746 is successfully created for this GitHub issue.

[m2-assistant]

✅ Confirmed by @engcom-Echo. Thank you for verifying the issue.
Issue Available: @engcom-Echo, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.