Incorrect EAV reindex: disabled product indexed when enabled on another store view (multistore)

[kdivan]

Preconditions and environment

Preconditions

• Magento Open Source 2.4.8-p3 (fresh install with sample data, no third-party modules)
• PHP 8.4
• MySQL 8.4
• 2 store views

Setup

First, retrieve the attribute IDs for your installation (they may vary):

SELECT attribute_id, attribute_code
FROM eav_attribute
WHERE attribute_code IN ('status', 'visibility')
AND entity_type_id = 4;

In the examples below, we use {STATUS_ID} and {VISIBILITY_ID} as placeholders for these values.

Configure product 24-MB01 as follows:

Scope	Status	Visibility
Default (store 0)	Disabled	Catalog, Search
Store View 1	Disabled (inherits default)	Catalog, Search (store-level override)
Store View 2	Enabled (store-level override)	Catalog, Search (inherits default)

Resulting EAV data:

-- Status values (attribute_id = {STATUS_ID})
SELECT store_id, value FROM catalog_product_entity_int
WHERE entity_id = {PRODUCT_ID} AND attribute_id = {STATUS_ID};
-- store_id=0, value=2 (Disabled)
-- store_id=2, value=1 (Enabled)

-- Visibility values (attribute_id = {VISIBILITY_ID})
SELECT store_id, value FROM catalog_product_entity_int
WHERE entity_id = {PRODUCT_ID} AND attribute_id = {VISIBILITY_ID};
-- store_id=0, value=4 (Catalog, Search)
-- store_id=1, value=4 (Catalog, Search)

Root Cause

The bug is in Magento\Catalog\Model\ResourceModel\Product\Indexer\Eav\Source::_prepareSelectIndex().

When $entityIds is not null, a $selectWithoutDefaultStore query is built and UNIONed with the main query. This second query has an incorrect JOIN condition for the status check:

Buggy code (line 268):

->joinLeft(
    ['d2s' => $this->getTable('catalog_product_entity_int')],
    "d2s.store_id != 0 AND d2s.attribute_id = d2d.attribute_id AND " .
    "d2s.{$productIdField} = d2d.{$productIdField}",
    []
)

The d2s.store_id != 0 matches the status attribute from any non-default store. If the product is Enabled on any store, COALESCE(d2s.value, d2d.value) evaluates to 1 (Enabled), causing the product to
be indexed for all stores where it has a visibility row — regardless of whether the product is actually Disabled on that specific store.

The main query in the same method correctly uses d2s.store_id = s.store_id (line
199):

->joinLeft(
    ['d2s' => $this->getTable('catalog_product_entity_int')],
    "d2s.store_id = s.store_id AND d2s.attribute_id = d2d.attribute_id AND " .
    "d2s.{$productIdField} = d2d.{$productIdField}",
    []
)

Why full reindex is also affected

The $selectWithoutDefaultStore query is built whenever $entityIds !== null. Even full reindex is affected because
Action\Full::execute() processes products in batches, calling
reindexEntities($batchOfIds) per batch. Since $entityIds is never null in practice, the buggy query is always built — for both full and partial (cron) reindex.

SQL proof of the bug

Note: Replace {STATUS_ID}, {VISIBILITY_ID} and {PRODUCT_ID} with the actual attribute IDs and the product's entity_id on your installation.

-- Simulates the buggy selectWithoutDefaultStore JOIN
-- For store 1 (DISABLED), it picks up ENABLED status from store 2
SELECT
    wd.store_id AS indexing_for_store,
    d2s.store_id AS status_taken_from_store,
    d2s.value AS status_value,
    CASE WHEN wd.store_id != d2s.store_id THEN 'WRONG STORE' ELSE 'OK' END AS problem
FROM catalog_product_entity_int wd
JOIN catalog_product_entity cpe ON cpe.entity_id = wd.entity_id
LEFT JOIN catalog_product_entity_int d2d
    ON d2d.store_id = 0 AND d2d.entity_id = wd.entity_id AND d2d.attribute_id = {STATUS_ID}
LEFT JOIN catalog_product_entity_int d2s
    ON d2s.store_id != 0  -- BUG: matches ANY store
    AND d2s.attribute_id = d2d.attribute_id
    AND d2s.entity_id = d2d.entity_id
WHERE cpe.entity_id = {PRODUCT_ID}
    AND wd.attribute_id = {VISIBILITY_ID}
    AND wd.store_id = 1
    AND COALESCE(d2s.value, d2d.value) = 1;

-- Result:
-- indexing_for_store=1, status_taken_from_store=2, status_value=1, problem=WRONG STORE

Proposed Fix

Change d2s.store_id != 0 to d2s.store_id = wd.store_id in the $selectWithoutDefaultStore query to match the main query's behavior:

--- a/app/code/Magento/Catalog/Model/ResourceModel/Product/Indexer/Eav/Source.php
+++ b/app/code/Magento/Catalog/Model/ResourceModel/Product/Indexer/Eav/Source.php
@@ -265,7 +265,7 @@
             )->joinLeft(
                 ['d2s' => $this->getTable('catalog_product_entity_int')],
-                "d2s.store_id != 0 AND d2s.attribute_id = d2d.attribute_id AND " .
+                "d2s.store_id = wd.store_id AND d2s.attribute_id = d2d.attribute_id AND " .
                 "d2s.{$productIdField} = d2d.{$productIdField}",
                 []
             )

Impact

• Affected versions: 2.4.8-p3 (confirmed), likely all 2.4.x versions (the buggy code has never been modified since introduction)
• Trigger condition: Multistore setup + product Enabled on at least one store and Disabled on another + store-level visibility override exists on a disabled store
• Consequence: Disabled products appear in layered navigation filters and attribute-filtered catalog queries for stores where they should be hidden
• No workaround: Full reindex is also affected (Action\Full processes products in batches, so $entityIds is never null)

Steps to reproduce

1. Install Magento 2.4.8-p3 with sample data
2. Create a second store view
3. For product 24-MB01:
   • Set default scope status to Disabled
   • Set Store View 2 status to Enabled (store-level override)
   • Set Store View 1 visibility to Catalog, Search (store-level override, to create a store_id != 0 row)
4. Run: bin/magento indexer:reindex catalog_product_attribute
5. Check catalog_product_index_eav

Expected result

Product should only be indexed for Store View 2 (where it is Enabled).

+--------+----------+-----+
| entity | store_id | val |
+--------+----------+-----+
|      1 |        2 |   4 |  ← Correct: Enabled on store 2
+--------+----------+-----+

Actual result

Product is incorrectly indexed for both Store View 1 and Store View 2, even though it is Disabled on Store View 1.

+--------+----------+-----+
| entity | store_id | val |
+--------+----------+-----+
|      1 |        1 |   4 |  ← BUG: Disabled on store 1 but indexed
|      1 |        2 |   4 |  ← Correct
+--------+----------+-----+

Additional information

No response

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

[m2-assistant]

Hi @kdivan. Thank you for your report.
To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce.

• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this
• To learn more about issue processing workflow, refer to the Code Contributions.

---

Join Magento Community Engineering Slack and ask your questions in #github channel.
⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
🕙 You can find the schedule on the Magento Community Calendar page.
📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.

[m2-assistant]

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

  - 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-Bravo]

Hi @kdivan,

Thanks for your reporting and collaboration.

We have tried to reproduce the issue in Latest 2.4-develop instance and we are not able to reproduce the issue could you please elaborate regarding enabling the product since enable product is in website scope.do we need to create multiple websites or multiple stores if possible please provide screenshots or screencast.

Thanks.

[kdivan]

Hi @engcom-Bravo,

Thanks for looking into this. Here are corrected reproduction steps using 2 websites, fully reproducible through the standard admin panel.

Setup

1. Create 2 websites with store views

Go to Stores > All Stores and create:

Website	Store	Store View	Store View ID
Main Website	Main Store	Default Store View	1
Second Website	Second Store	Second Store View	2

2. Configure a product (e.g. 24-MB01)

• Go to Catalog > Products > 24-MB01
• Assign product to both websites (Main Website + Second Website)
• Default scope (All Store Views): Status = Disabled, Visibility = Catalog, Search
• Switch scope to Second Website: Set Status = Enabled (uncheck "Use Default Value")
• Switch scope to Default Store View (store_id=1): Set Visibility = Catalog, Search (uncheck "Use Default Value" to create a store-view-level override)
• Save

3. Verify EAV data

-- Get attribute IDs (adjust for your install)
SELECT attribute_id, attribute_code
FROM eav_attribute
WHERE attribute_code IN ('status', 'visibility') AND entity_type_id = 4;
-- Example: status = 97, visibility = 99

-- Get product entity_id
SELECT entity_id FROM catalog_product_entity WHERE sku = '24-MB01';
-- Example: entity_id = 1

-- Status values
SELECT store_id, value FROM catalog_product_entity_int
WHERE entity_id = 1 AND attribute_id = 97;

-- Visibility values
SELECT store_id, value FROM catalog_product_entity_int
WHERE entity_id = 1 AND attribute_id = 99;

Expected data:

store_id	attribute	value
0	status	2 (Disabled — default)
2	status	1 (Enabled — Second Website override)
0	visibility	4 (Catalog, Search)
1	visibility	4 (Catalog, Search — store view override)

Important: The store-view-level visibility override for store_id=1 is critical — it triggers the $selectWithoutDefaultStore code path in Source::_prepareSelectIndex().

Steps to Reproduce

1. Complete the setup above
2. Run:

bin/magento indexer:reindex catalog_product_attribute

3. Query the EAV index:

SELECT entity_id, attribute_id, store_id, value
FROM catalog_product_index_eav
WHERE entity_id = 1 AND store_id = 1;

Expected Result

Product 24-MB01 does NOT appear in catalog_product_index_eav for store_id=1, because it is Disabled on Main Website (inherits default).

Actual Result

Product 24-MB01 incorrectly appears in catalog_product_index_eav for store_id=1. The Enabled status from Second Website (store_id=2) bleeds into Main Website's index, making a disabled product visible in layered navigation and attribute filters.