Varnish cache is cleared for the product and categories after an order is placed

[bmitchell-ldg]

Preconditions (*)

1. Magento 2.3.5
2. Varnish-6.0.6
3. Elasticsearch 6
4. PHP 7.2.30

Steps to reproduce (*)

1. Go to a category page and inspect the page and refresh until you see a x-cache HIT confirming that the page is being cached
2. Pick a simple product on that category page and on the product page inpect the page and refresh until you see the x-cache HIT confirming that the page is being cached
3. purchase that product
4. within the next couple of minutes you will see a purge request sent to varnish for that product i assume because the stock level changed (product saved)
   • ReqMethod PURGE
   • ReqURL /
   • ReqHeader X-Magento-Tags-Pattern: ((^|,)cat_p_43(,|$))
5. refresh the category and product pages and see the x-cache MISS for both the category and product pages related to that specific product

The more categories the product is related to the more of an issue it causes for the website as all of the categories related to the product are being purged.

Expected result (*)

1. Since the actual stock level is not something that is displayed on the frontend as default, then i can't think of a reason why it should need to purge the cache everytime the quantity changes. I would have thought it would only carry out the cache purge if the stock status had changed because it would need to show the new instock/out of stock status on the product/category pages. Any website with fast selling products is never going to be able to keep the cache warm.

Actual result (*)

1. Placing an order causes all cache tags related to that product to be cleared.

Severity: S2

[m2-assistant[bot]]

Hi @bmitchell-ldg. 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.

Please, add a comment to assign the issue: @magento I am working on this

---

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

  :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

:clock10: You can find the schedule on the Magento Community Calendar page.

:telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

:movie_camera: You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

:pencil2: Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[bmitchell-ldg]

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

[magento-deployment-service[bot]]

Hi @bmitchell-ldg. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @bmitchell-ldg, here is your Magento Instance: https://ba8cde84d445e9fcbadaf56604f12566-2-4-develop.instances.magento-community.engineering Admin access: https://ba8cde84d445e9fcbadaf56604f12566-2-4-develop.instances.magento-community.engineering/admin_2661 Login: 83239c15 Password: af57ffb8d7f0

[bmitchell-ldg]

Hello, I am unable to use varnish on the 2.4 testing instance to be able to fully replicate the issue we are seeing, but i have been able to see the same behaviour using the built in cache on product pages.

*Product Page Cache Tests I have added screenshots below

• Screenshot shows the page load on a cached page
• I have then placed an order for the product
• a couple of minutes after the order is placed, you can see the cache has been purged for that product, you can see it by the page load time increase when inspecting the network tab.

[bmitchell-ldg]

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

[magento-deployment-service[bot]]

Hi @bmitchell-ldg. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @bmitchell-ldg, here is your Magento Instance: https://ba8cde84d445e9fcbadaf56604f12566-2-4-develop.instances.magento-community.engineering Admin access: https://ba8cde84d445e9fcbadaf56604f12566-2-4-develop.instances.magento-community.engineering/admin_6ac7 Login: b181955d Password: e69706295bad

[gwharton]

Could be because of "only X left" functionality. If so it should only clear cache if qty is less than threshold I guess.

[bmitchell-ldg]

@gwharton thank you for your suggestion, i set "only X left" functionality to 0 for all sites in case it was that and it's unfortunately still an issue for us. When we place an order, a purge request is sent to varnish for the products in the order, which i think isn't expected behaviour. Example 1 order containing 8 products, 1 purge request sent to varnish containing the cache tags for those 8 products causing them to go to a cache MISS. I'm currently debugging this now, so will hopefully have some more information soon.

[bmitchell-ldg]

I disabled all of our custom modules and any 3rd party ones and it was still happening, i think it might be down to a plugin called afterUpdateMview in vendor/magento/module-indexer/Model/Processor/CleanCache.php which i can see being called after the reindex has completed

I added some logging to our dev enviroment and i can see that when the order is placed it actions a function called clean in vendor/magento/module-catalog-inventory/Model/Indexer/Stock/CacheCleaner.php which has the logic in to see if the stock status has changed and this only purges the caches if the status is changed and not the stock level which works perfectly.

but then afterUpdateMview is actioned and sends the purge

[2021-01-29 13:25:08] report.INFO: After update mview [["cat_p_837","cat_p_837"]] [] [2021-01-29 13:25:08] report.INFO: Bare Tags [["cat_p_837","cat_p_837"]] [] [2021-01-29 13:25:08] report.INFO: Sending purge request for Tags [["((^|,)cat_p_837(,|$))","((^|,)cat_p_837(,|$))"]] [] [2021-01-29 13:25:08] report.INFO: Cron Job indexer_update_all_views is successfully finished.

Varnish output << Request >> 2064457

• ReqMethod PURGE
• ReqHeader X-Magento-Tags-Pattern: ((^|,)cat_p_837(,|$))
• RespReason Purged
• RespHeader Date: Fri, 29 Jan 2021 13:25:08 GMT
• RespHeader Server: Varnish

Will continue debugging and update when i find anything else

[bmitchell-ldg]

Spent a little more time looking into this and found the following; When an order is placed depending on if the stock status is changed it either sends 2 or 3 purges to varnish.

Place an order with a product that has plenty of stock and the purges are sent from

• Magento\Indexer\Model\Processor\CleanCache function called afterUpdateMview
• Magento\Indexer\Model\Indexer\CacheCleaner function called afterExecuteList

Place an order but make the product out of stock (the stock status changes) and the purges are sent from

• Magento\Indexer\Model\Processor\CleanCache function called afterUpdateMview
• Magento\Indexer\Model\Indexer\CacheCleaner function called afterExecuteList
• Magento\CatalogInventory\Model\Indexer\Stock\CacheCleaner function called clean

The correct logic to only purge the cache if the stock status changes is in Magento\CatalogInventory\Model\Indexer\Stock\CacheCleaner so i'm trying to figure out why a purge is also sent from the other two (afterUpdateMview, afterExecuteList) if i remove those after plugins everything still flushes as expected when it's supposed to (regarding actions to stock, pricing, product data, categories etc).

[bmitchell-ldg]

In our instance we removed both after plugins Magento\Indexer\Model\Processor\CleanCache function called afterUpdateMview Magento\Indexer\Model\Indexer\CacheCleaner function called afterExecuteList

The only issue we found when removing those two plugins was the purge not being sent for the $stockThresholdQty logic in Magento\CatalogInventory\Model\Indexer\Stock\CacheCleaner when it needed to flush the cache to change the X amount qty display on the frontend (everything else regarding stock, products, categories and attributes purged as expected).

$stockThresholdQty = $this->stockConfiguration->getStockThresholdQty(); returns $this->scopeConfig->getValue(self::XML_PATH_STOCK_THRESHOLD_QTY,ScopeInterface::SCOPE_STORE,$store);

But i realised the storeId is not passed in at this point so it was just taking the value from the default store, in our instance we have 12 stores so it wasn't purging the cache for the products that fell into the check to see if $statusAfter['qty'] <= $stockThresholdQty because we had the value set to 0 at default store.

Another thing we noticed is if you have $stockThresholdQty set to 0 at default store it makes the configurable product cache be purged on every order placed because $statusAfter['qty'] is always 0. Example of the output for $statusAfter after buying a child product

Product status before [{"837":{"product_id":"837","stock_status":"1","qty":"124.0000","parent_id":"21176"}, "20326":{"product_id":"20326","stock_status":"1","qty":"0.0000","parent_id":null}, "21176":{"product_id":"21176","stock_status":"1","qty":"0.0000","parent_id":null}}] []

Product status after [{"837":{"product_id":"837","stock_status":"1","qty":"123.0000","parent_id":"21176"}, "20326":{"product_id":"20326","stock_status":"1","qty":"0.0000","parent_id":null}, "21176":{"product_id":"21176","stock_status":"1","qty":"0.0000","parent_id":null}}] []

As a quick work around we;

• created patches to remove the two after plugins

• changed the default value for Only X left Threshold (cataloginventory/options/stock_threshold_qty) to a value we would be happy to use for all stores

• Added a preference for Magento\CatalogInventory\Model\Indexer\Stock\CacheCleaner and changed the logic for getProductIdsForCacheClean to

and changed the clean function to to take care of cache flushes for configurable products with swatches

This is only a workaround until a full solution can be looked at, but saves the caches from being unnecessarily flushed. We will extensively test this in both dev and live environments.

[gregorybesson]

Hello @bmitchell-ldg and thanks for your detailed study.

I'm working on a 2.4.1 EE version and had the same problem. You're detailed explanation has been invaluable to me.

Your solution was almost ok, but I've added another fix to take care of the stock/source reindex which produces a cache clear on the items also.

The total fix is something like that:

di.xml

<!-- These AOP after methods from the Magento 2 core clear the cache (when stock/source is in SYNC mode) after an order -->
<!-- has been placed even when the status of the products has not changed (but the qty has changed) -->
<!-- this bug : https://github.com/magento/magento2/issues/30128 -->
<!-- does show the problem + part of the solution -->
<!-- The impact is huge on perf. See the documentation for details -->
<type name="Magento\Indexer\Model\Processor">
    <plugin name="page-cache-indexer-reindex-clean-cache" disabled="true"/>
</type>
<type name="Magento\Framework\Indexer\ActionInterface">
    <plugin name="cache_cleaner_after_reindex" disabled="true"/>
</type>
<type name="Magento\InventoryIndexer\Indexer\SourceItem\Strategy\Sync">
    <plugin name="invalidate_products_cache" disabled="true"/>
    <plugin name="lc_invalidate_products_cache" type="LivingColor\Api\Plugin\InventoryIndexer\Indexer\SourceItem\Strategy\Sync\CacheFlush"/>
</type>
<type name="LivingColor\Api\Model\ResourceModel\GetProductIdsBySourceItemIds">
    <arguments>
        <argument name="productTableName" xsi:type="string">catalog_product_entity</argument>
    </arguments>
</type>

LivingColor\Api\Plugin\InventoryIndexer\Indexer\SourceItem\Strategy\Sync\CacheFlush: (the only change is the usage of use LivingColor\Api\Model\ResourceModel\GetProductIdsBySourceItemIds to select only products changing status

<?php
declare(strict_types=1);

namespace LivingColor\Api\Plugin\InventoryIndexer\Indexer\SourceItem\Strategy\Sync;

use Magento\InventoryCache\Model\FlushCacheByProductIds;
use Magento\InventoryIndexer\Indexer\SourceItem\Strategy\Sync;
use LivingColor\Api\Model\ResourceModel\GetProductIdsBySourceItemIds;

/**
 * Clean cache for corresponding products after source item reindex.
 */
class CacheFlush
{
    /**
     * @var FlushCacheByProductIds
     */
    private $flushCacheByIds;

    /**
     * @var GetProductIdsBySourceItemIds
     */
    private $getProductIdsBySourceItemIds;

    /**
     * @param FlushCacheByProductIds $flushCacheByIds
     * @param GetProductIdsBySourceItemIds $getProductIdsBySourceItemIds
     */
    public function __construct(
        FlushCacheByProductIds $flushCacheByIds,
        GetProductIdsBySourceItemIds $getProductIdsBySourceItemIds
    ) {
        $this->flushCacheByIds = $flushCacheByIds;
        $this->getProductIdsBySourceItemIds = $getProductIdsBySourceItemIds;
    }

    /**
     * Clean cache for specific products after source items reindex.
     *
     * @param Sync $subject
     * @param void $result
     * @param array $sourceItemIds
     * @throws \Exception in case catalog product entity type hasn't been initialized.
     * @SuppressWarnings(PHPMD.UnusedFormalParameter)
     */
    public function afterExecuteList(Sync $subject, $result, array $sourceItemIds)
    {
        $productIds = $this->getProductIdsBySourceItemIds->execute($sourceItemIds);
        $this->flushCacheByIds->execute($productIds);
    }
}

Last but not least

LivingColor\Api\Model\ResourceModel\GetProductIdsBySourceItemIds

<?php
declare(strict_types=1);

namespace LivingColor\Api\Model\ResourceModel;

use Magento\Framework\App\ResourceConnection;
use Magento\Inventory\Model\ResourceModel\SourceItem;
use Magento\InventoryApi\Api\Data\SourceItemInterface;

/**
 * Provides product ids related to specified source items ids.
 */
class GetProductIdsBySourceItemIds
{
    /**
     * @var ResourceConnection
     */
    private $resource;

    /**
     * @var string
     */
    private $productTableName;

    /**
     * @param ResourceConnection $resource
     * @param string $productTableName
     */
    public function __construct(
        ResourceConnection $resource,
        string $productTableName
    ) {
        $this->resource = $resource;
        $this->productTableName = $productTableName;
    }

    /**
     * Get product ids related to specified source items.
     * We've added the filter on stock status. The calculation is not definitely good
     * as it could fail if multiple sources are used (the sum of the quantity of a SKU has to be done)
     * or all the sources have to declare the SKU as out of stock to be good.
     *
     * But for now it's enough : We have only one source.
     * This way, we clear the cache ONLY when the product is out of stock.
     *
     * @param array $sourceItemIds
     * @return array
     */
    public function execute(array $sourceItemIds): array
    {
        $connection = $this->resource->getConnection();
        $outOfStockStmt = new \Zend_Db_Expr(
            'source_item.' . SourceItemInterface::QUANTITY . ' = 0 OR source_item.' . SourceItemInterface::STATUS . ' = ' . SourceItemInterface::STATUS_OUT_OF_STOCK
        );
        $select = $connection->select()
            ->from(
                ['source_item' => $this->resource->getTableName(SourceItem::TABLE_NAME_SOURCE_ITEM)],
                []
            )->where(
                'source_item.' . SourceItem::ID_FIELD_NAME . ' IN (?)',
                $sourceItemIds
            )->where(
                $outOfStockStmt
            )->join(
                ['product' => $this->resource->getTableName($this->productTableName)],
                'source_item.' . SourceItemInterface::SKU . ' = product.sku',
                ['product.entity_id']
            )->distinct();

        return $connection->fetchCol($select);
    }
}

Hope it will help Magento team to fix / improve it.

Greg

[stale[bot]]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 14 days if no further activity occurs. Is this issue still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? Thank you for your contributions!

[bartoszkubicki]

doesnt seem to be resolved

[m2-assistant[bot]]

Hi @engcom-Echo. 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.

[jitheesh-db]

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

[magento-deployment-service[bot]]

Hi @jitheesh-lumi. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @jitheesh-lumi, here is your Magento Instance: https://ba8cde84d445e9fcbadaf56604f12566-2-4-develop.instances.magento-community.engineering Admin access: https://ba8cde84d445e9fcbadaf56604f12566-2-4-develop.instances.magento-community.engineering/admin_596c Login: 0e7d09a3 Password: 6d3666c12e35

[mrtuvn]

@bmitchell-ldg have you recheck this problem at latest code ?

[nemanjamm]

In our instance we removed both after plugins Magento\Indexer\Model\Processor\CleanCache function called afterUpdateMview Magento\Indexer\Model\Indexer\CacheCleaner function called afterExecuteList

The only issue we found when removing those two plugins was the purge not being sent for the $stockThresholdQty logic in Magento\CatalogInventory\Model\Indexer\Stock\CacheCleaner when it needed to flush the cache to change the X amount qty display on the frontend (everything else regarding stock, products, categories and attributes purged as expected).

$stockThresholdQty = $this->stockConfiguration->getStockThresholdQty(); returns $this->scopeConfig->getValue(self::XML_PATH_STOCK_THRESHOLD_QTY,ScopeInterface::SCOPE_STORE,$store);

But i realised the storeId is not passed in at this point so it was just taking the value from the default store, in our instance we have 12 stores so it wasn't purging the cache for the products that fell into the check to see if $statusAfter['qty'] <= $stockThresholdQty because we had the value set to 0 at default store.

Another thing we noticed is if you have $stockThresholdQty set to 0 at default store it makes the configurable product cache be purged on every order placed because $statusAfter['qty'] is always 0. Example of the output for $statusAfter after buying a child product

Product status before [{"837":{"product_id":"837","stock_status":"1","qty":"124.0000","parent_id":"21176"}, "20326":{"product_id":"20326","stock_status":"1","qty":"0.0000","parent_id":null}, "21176":{"product_id":"21176","stock_status":"1","qty":"0.0000","parent_id":null}}] []

Product status after [{"837":{"product_id":"837","stock_status":"1","qty":"123.0000","parent_id":"21176"}, "20326":{"product_id":"20326","stock_status":"1","qty":"0.0000","parent_id":null}, "21176":{"product_id":"21176","stock_status":"1","qty":"0.0000","parent_id":null}}] []

As a quick work around we;

• created patches to remove the two after plugins
• changed the default value for Only X left Threshold (cataloginventory/options/stock_threshold_qty) to a value we would be happy to use for all stores
• Added a preference for Magento\CatalogInventory\Model\Indexer\Stock\CacheCleaner and changed the logic for getProductIdsForCacheClean to

and changed the clean function to to take care of cache flushes for configurable products with swatches

This is only a workaround until a full solution can be looked at, but saves the caches from being unnecessarily flushed. We will extensively test this in both dev and live environments.

@bmitchell-ldg can you share repo with patches or patches here? Thank you

[mrtuvn]

Lol

[mrtuvn]

Right now a lot of code changed but i don't see author response any new updates. Feel free to recheck problem with 2.4.3 https://github.com/magento/magento2/blob/2.4-develop/app/code/Magento/CatalogInventory/Model/Indexer/Stock/CacheCleaner.php#L83

[mrtuvn]

@bmitchell-ldg can you have time for check in 2.4 develop code

[engcom-Hotel]

Hello @bmitchell-ldg,

Can you please try to reproduce this issue in the 2.4-develop branch?

Thanks

[m2-assistant[bot]]

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: :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.

[engcom-Hotel]

Hello @bmitchell-ldg,

We have noticed that this issue has not been updated for a period of 14 Days. Hence we assume that this issue is fixed now, so we are closing it. Please raise a fresh ticket or reopen this ticket if you need more assistance on this.

Regards

[multipasko]

The problem is still there on Magento 2.4.3

[multipasko]

@gregorybesson thanks for your code. How is it going to work if product out of stock wants to get back to be "in stock". It seems your code would clear the cache only when getting to out of stock and not do it again when the inventory gets back positive.

[gregorybesson]

@gregorybesson thanks for your code. How is it going to work if product out of stock wants to get back to be "in stock". It seems your code would clear the cache only when getting to out of stock and not do it again when the inventory gets back positive.

Hello @multipasko you're fully right, this use case should be taken into account. It's not the case in the fix I've proposed

[kestraly]

As a side note, I've found FPC being cleared completely is mainly down to some indexers behviour and plugin behviour. I found the Amasty indexes introduced by Amasty Sorting module, Amasty Produc grid, if left to index on schedule and not on save will continuously clear the FPC. The Swissup Checkout Fields introduces an FPC clear when an order is saved. It's not entirely the modules fault though, it just states the module has a cache for the fields and the FPC clear is introduced on saving the entry.

[korostii]

FYI anyone whom this may concern: this issue is supposedly being fixed in 2.4.4, at least according to the beta's releases notes.

[onlinebizsoft]

FYI anyone whom this may concern: this issue is supposedly being fixed in 2.4.4, at least according to the beta's releases notes.

do you know how we can find out which issue/pull request are included in the release 2.4.4?

[hostep]

@onlinebizsoft: they link to https://github.com/magento/magento2/pull/33468 from the release notes.

You can find this by viewing the source code of the release notes, every issue is being prepended by some reference to a ticket number or something else and searching github for this can often show you want they reference there, example:

[onlinebizsoft]

@hostep I'm not very clear about the git flow of Magento product, not sure when this git repository (2.4-develop branch) merged into release,.....if there is any easy way or some points where we can see all issues or pull requests will be included in 2.4.4 release then it would be great.

[hostep]

@onlinebizsoft: most details can be found in the release notes (there is a chance these aren't finalised yet, because it's on the "beta" devdocs environment). At the bottom of the release notes, there is a big amount of links to github issues and pull requests.

Hope this helps a bit 🙂

[Legeakademiet]

@

Right now a lot of code changed but i don't see author response any new updates. Feel free to recheck problem with 2.4.3 https://github.com/magento/magento2/blob/2.4-develop/app/code/Magento/CatalogInventory/Model/Indexer/Stock/CacheCleaner.php#L83

Did you manage to fix it? We have the problem at with version 2.4.3.

[websecureNL]

We are experiencing a related problem when stock updates are done through the API. We use an order picking system that updates stock through API. When stock is updated, cache of the product and associated categories are purged. We are on 2.4.5. For us this means that cache is kept for less than half an hour on average. If it's true stock is also cleared on checkout it might even be worse (we are testing our new site on staging, so no orders yet).

[kestraly]

@websecureNL - That one is the most annoying at present. If you’re doing mass stock updates for all products, the indexing triggers the FPC to be cleared. So a mass action for all products does exactly the same. What’s annoying is, it’s not an FPC update at the end of the cycle, it’s an FPC one after the other. So 25,000 products updated and it clears FPC 25,000 times in all the logs that I’ve checked so far. A real drain

[jakegore]

@websecureNL Did anyone find a fix/workaround for this? We appear to be having this issue on a store that we just recently updated to 2.4.5-p1.

[frostitution]

Dealing with this right now on 2.4.4 EE

I saw this PR https://github.com/magento/magento2/issues/33465 but oddly I am still seeing those same magento tags on all my pages still, so I am not sure the PR worked, or something else is causing the magento tags to appear still.

[JelleGe]

Is this issue solved in 2.4.6? What files are exactly changed to solve the issue?

[bmitchell-ldg]

Noticed this mentioned in the release notes for 2.4.4 "Placing an order no longer results in the removal of all cache tags that are related to the ordered products from the Varnish cache. GitHub-30128" I can confirm this is still an issue in 2.4.5, we placed an order for a product that has hundreds in stock, and the varnish cache was purged for the product and all related categories.

[hostep]

@bmitchell-ldg, just guessing here, but maybe this thread helps: https://github.com/magento/magento2/issues/36813 This is supposed to be fixed in the MSI modules version 1.2.6 (which gets included in Magento 2.4.6)

From MSI release notes:

• Fixed issue Category page caches are no longer invalidated when stock quantity changes and the product is still in stock. Adobe Commerce now loads pages from the cache instead of regenerating them when product quantity (and nothing else) on the storefront category page changes.

...

• Fixed issue Updating product inventory in scheduled mode no longer clears all caches. Previously, the Inventory indexer cleared all configuration caches.

[alexryall]

This does appear to be fixed in 2.4.6 but not because of https://github.com/magento/magento2/issues/36813 as this is a different issue where everything gets flushed and this issue is when particular products that are ordered are flushed.

vendor/magento/module-indexer/Model/Indexer/DeferredCacheCleaner.php

public function flush(): void
    {
        $this->deferredCacheContext->commit();
        $this->eventManager->dispatch('clean_cache_by_tags', ['object' => $this->cacheContext]);
        $identities = $this->cacheContext->getIdentities();
        if (!empty($identities)) {
            $this->appCache->clean($identities);
            $this->cacheContext->flush();
        }
    }

In 2.4.5 $identities contains the tags for the unchanged products and flushes the cache. In 2.4.6 $identities is empty so the if check fails and is passed over. I haven't been able to find the change that has fixed this so will likely be looking to upgrade to 2.4.6 rather than patching our current version.

[alexryall]

This is the change in 2.4.6 that fixes this issue once and for all. https://github.com/magento/magento2/commit/b3969936251e1a03427cd24c209abb6af3a0ce1b

[farrukhk]

This is working for simple products but for configurable products cache is still being flushed. Is there a way to fix that too?