We are facing an intermittent issue in a Magento 2 production store where category/search product listing breaks randomly.
Environment:
Magento Version: 2.4.8-p5
PHP Version: 8.2.x
Search Engine: OpenSearch
OpenSearch: running locally on the same server
Index Prefix: custom Magento index prefix
Product aliases are similar to:
[index_prefix]_product_1
[index_prefix]_product_2
Issue:
Sometimes the frontend category/search product listing fails with this error:
OpenSearchCommonExceptionsMissing404Exception
no such index [[index_prefix]_product_1]
When this happens, products are still available in Magento admin and database. The issue is only with the OpenSearch product index/alias.
We created a small monitor script to check the product aliases every minute. During one real incident, the monitor detected that both product aliases returned 404:
product_1=404
product_2=404
BEFORE aliases:
none
BEFORE indexes:
none
Then we manually/automatically ran:
php bin/magento indexer:reindex catalogsearch_fulltext
php bin/magento cache:clean
After that, aliases/indexes were recreated and frontend listing started working again:
AFTER product_1=200
AFTER product_2=200
In an older OpenSearch log, we saw lines similar to:
MetadataDeleteIndexService
[[index_prefix]_product_1_v2/…] deleting index
[[index_prefix]_product_2_v2/…] deleting index
But the OpenSearch log only shows that OpenSearch deleted the index. It does not show which Magento process, cron job, module, or request triggered the delete.
Magento cron is running every minute:
-
-
-
-
- php /path/to/magento/bin/magento cron:run >> /path/to/magento/var/log/magento.cron.log
-
-
-
We also see Magento indexer cron jobs running around the same time, such as:
indexer_reindex_all_invalid
indexer_update_all_views
catalogsearch_fulltext
Questions:
What can cause Magento/OpenSearch product aliases like [index_prefix]_product_1 and [index_prefix]_product_2 to disappear?
Can the catalogsearch_fulltext indexer alias swap process delete the old index before the new alias is safely created?
Is there any known race condition or cron overlap issue with Magento 2.4.8-p5 and OpenSearch catalog search indexing?
How can we identify the exact caller that sent the delete-index request to OpenSearch?
Is there any safe way to prevent frontend breakage when the product alias/index is missing?
Could running Magento cron from a different Linux user than the Magento file owner cause this type of OpenSearch alias/index issue?
Current workaround:
We have a monitor script that checks the product aliases. If either alias returns 404, it runs:
php bin/magento indexer:reindex catalogsearch_fulltext
php bin/magento cache:clean
This restores the indexes quickly, but we want to find and fix the actual root cause.
Any guidance on debugging this issue properly would be helpful.
