As low as price shows wrong on configurable product after REST API stock update

[Vatsal-Patel1]

Preconditions and environment

Tested on this version(s):

Magento Version: dev-2.4-develop
Indexer Mode: Update By schedule (Use cron run for partial indexing)

Issue Description:

Consider a configurable product with two simple product variants having different prices — for example:

• Variant A: Price 500 (in stock)
• Variant B: Price 100 (out of stock)

Since Variant B has the lower price, it initially determines the configurable product's displayed "As low as" price. When Variant B is set to Out of Stock from the admin panel, the configurable product correctly starts showing Variant A's price (100) as the lowest price.

However, when Variant B is set back to In Stock via the REST API (PUT rest/V1/products/{sku}/stockItems/{id}) instead of the admin panel, the price index does not get updated correctly during partial reindexing. As a result, the configurable product page continues to show the wrong variant's price (100) instead of falling back to the actual lowest price (50) from Variant B.

Screenshot-1: Configurable product with two variants and different prices

Screenshot-2: Variant B marked Out of Stock from admin panel

Screenshot-3: Storefront price after Variant B is Out of Stock (showing 500, as expected)

Screenshot-4: REST API request setting Variant B back to In Stock

Screenshot-5: Storefront price after partial reindex — incorrect price still shown

Steps to reproduce:

1. Take 2.4-develop branch clone.
2. Set all indexers to Update by Schedule mode and run cron so that partial (scheduled) indexing is triggered.
3. Create a configurable product with two variants having different prices (Screenshot-1).
4. Set the lower-priced variant to Out of Stock using the admin panel (Screenshot-2).
5. Wait for/trigger partial indexing and confirm the storefront now shows the higher-priced variant's price (Screenshot-3).
6. Set the same variant back to In Stock using the REST API: PUT rest/V1/products/{sku}/stockItems/{id} (Screenshot-4).
7. Allow partial indexing to complete.
8. Reload the product page on the storefront and observe the displayed price (Screenshot-5).

Expected results:

the configurable product should display the correct lowest price among all in-stock variants

Actual results:

After setting the variant back to In Stock via the REST API, the configurable product continues to display the price of the other (higher-priced) variant instead of updating to reflect the actual lowest price, even after partial indexing has completed

Additional Information:

While saving a product from the admin panel, that product is added to the indexing backlog. This is related to the changes introduced in this commit:

1984c61

This commit made changes to the entity date handling and to the price mview table, so that on admin save, the product is correctly added to the price indexer backlog (catalog_product_price_indexer backlog / changelog table) for partial reindexing.

However, when the stock status is updated via REST API (PUT rest/V1/products/{sku}/stockItems/{id}), the product is not added to this indexing backlog. As a result, the price index is never refreshed for that product during partial (scheduled) indexing.

This explains the observed behavior:

1. When the variant is set to Out of Stock from the admin panel, the product save flow correctly adds it to the backlog, and partial indexing removes its price row from catalog_product_index_price — so the configurable product correctly falls back to the other variant's price.
2. When the variant is set back to In Stock via the REST API, the product is not added to the backlog, so partial indexing never re-inserts its price row into catalog_product_index_price. The configurable product therefore continues to show the wrong (other variant's) price, since the correct variant's price row is missing from the index.

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 @Vatsal-Patel1. 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.

[github-jira-sync-bot]

✅ Jira issue https://jira.corp.adobe.com/browse/AC-17944 is successfully created for this GitHub issue.