-
Notifications
You must be signed in to change notification settings - Fork 9.4k
Description
Preconditions and environment
- 2.4.8-p1
- multiple stores
- env variable MAGE_INDEXER_THREADS_COUNT > 1
- indexer/use_application_lock config : true
Steps to reproduce
- Invalidate catalog_category_product + catalog_product_category indexers
- Run
bin/magento cron:run --group index
to run indexer_reindex_all_invalid
Expected result
It should reindex properly
Actual result
SQLSTATE[42S02]: Base table or view not found: 1146 Table 'magento2.catalog_category_product_index_store1_tmp' doesn't exist, query was: DELETE FROM `catalog_category_product_index_store1_tmp
NB: this error is a bit misleading as the catalog_category_product
indexer did reindex properly at first.
Additional information
After some analysis, here is what I found:
When indexation starts, current indexer is locked (using a database lock by default).
When multithreads are starting, parent connections are closed so we are losing the DB locks:
https://github.com/magento/magento2/blob/2.4.8-p1/app/code/Magento/Indexer/Model/ProcessManager.php#L110
When indexation finishes, it checks if indexer is in a "working" state before to set it as "valid"
https://github.com/magento/magento2/blob/2.4.8-p1/app/code/Magento/Indexer/Model/Indexer.php#L471
However, in State::getStatus() function, if status is "working" but NOT locked, then it returns "invalid" instead...
https://github.com/magento/magento2/blob/2.4.8-p1/app/code/Magento/Indexer/Model/Indexer/State.php#L113
So it ends up keeping "working" state and not validating shared indexers (so catalog_product_category starts and the "Base table or view not found" appears).
The commit involved seems to be this one.
d09224a
Release note
No response
Triage and priority
- 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”.
Metadata
Metadata
Assignees
Labels
Type
Projects
Status