Description
In M2 the indexers have their specific order, e.g. price index must be reindexed prior to fulltext index etc.
When magento invalidates indexes, it takes the order of indexes into account.
Before 2.3.5, when an index got invalidated, it looked at the next indexes that were after it and which ever were declared as dependent on current, got invalidated as well.
In 2.3.5 and greater version upon invalidation, the index looks “both-ways” the indexes that came before and after it and were dependent got invalidated.
In clean 2.3.3, catalog_category index and catalogsearch_fulltext index get invalidated when for an example a product is removed from a category.
In clean 2.3.5 and greater version also price indexer and catalogrule indexer get invalidated because of the previously described both ways lookup. (also additionally both target-rule indexers and inventory indexer can get invalidated, depending on their state - update on save or mview)
The cause of the change was some Magento's internal ticket about not finding a product on Elasticsearch: 31aebbf
On a heavy traffic webshop(1k-3k continuous concurrent users) with a lot of products (around 100k) it is not possible to allow rebuilding of such amount of indexes on each category removal from product, as for an example the fulltext index alone takes around 10 minutes to rebuild. Removing and adding products to categories is a fairly common operation on daily bases and with current codebase the webshop enters a continues reindexing and cache cleaning loop.
Preconditions (*)
- Magento 2.4.0 or Magento 2.3.5 (Also present in 2.4-develop)
- Set in Admin -> System -> Index Managment all indexers to be 'Update by schedule'
Steps to reproduce (*)
- Remove a category from product on admin panel product edit form
Expected result (*)
- No (or as less as possible) indexes completely invalidated
Actual result (*)
- 6 indexes completely invalidated - bin/magento i:status command shows invalidated: catalogrule_rule, catalogsearch_fulltext, catalog_category_product, inventory, catalog_product_price, cataloginventory_stock forcing next incremental indexer run to reindex all of them
Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.
- Severity: S0 - Affects critical data or functionality and leaves users without workaround.
- Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
- Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
- Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
- Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.