Question and possibly bug: Delete and then insert in inventory_stock_{$id} might be causing out of stock issue

[adarshkhatri]

From time to time, the highest-selling product goes out of stock, even though there is plenty of stock still available and on top it is also set as Back order YES.

There is this code: https://github.com/magento/inventory/blob/adfc40b34f3de880f2b10861b84ec3cd69c3bd4b/InventoryIndexer/Indexer/Stock/IndexDataFiller.php#L70-L75

As you can see system is deleting the rows first and then inserting a new one. We think that when it deletes rows, and before it has inserted a new one, there is another processor that is trying to set salability: bin/magento queue:consumers:start inventory.reservations.updateSalabilityStatus, which will set the product to out of stock as it cannot find the row in the inventory stock table.

Why do we need to delete the row? There is insertOnDuplicate anyway.

Preconditions (*)

1. 2.4.6 Commerce

Steps to reproduce (*)

Hard to reproduce, we were able to reproduce only once in our dev env, and it keeps happening in prod.

Expected result (*)

1. Product is always in-stock

Actual result (*)

1. Time to time product is out of stock.

[m2-assistant[bot]]

Hi @adarshkhatri. Thank you for your report. To speed up processing of this issue, make sure that you provided sufficient information. Add a comment to assign the issue: @magento I am working on this

---

Join Magento Community Engineering Slack and ask your questions in #github channel.

[engcom-Hotel]

Hello @adarshkhatri,

Thank you for the report and collaboration!

We have tried to reproduce the issue in the latest development branch with the following steps:

1. Create a simple product
2. Assign quantity to the specific source other then default
3. Run bin/magento indexer:reindex
4. but for us this $skuList = $skuListInStock->getSkuList(); is always empty. https://github.com/magento/inventory/blob/f6594f02194fc00b62a8fe3d05ed37bdf2c7b2cd/InventoryIndexer/Indexer/Stock/IndexDataFiller.php#L55

Please let us know if we missed anything.

[adarshkhatri]

You shouldn't run a full reindex. Instead, you should rely on partial reindex.

In our case, we don't run a full reindex but let Magento do its normal duty. For example, when orders are placed, and orders are processed system runs these consumers, which will be running the necessary indexers in the background.

bin/magento queue:consumers:start inventory.indexer.sourceItem
bin/magento queue:consumers:start inventory.indexer.stock
bin/magento queue:consumers:start inventory.reservations.updateSalabilityStatus

And I confirm it is very hard to catch/replicate. You may want to run JMeter to achieve normal busy day behaviour.

But looking at the code, we see that it deletes first and then inserts, which does explain the possibility of a product going to OOS momentarily.

[engcom-Hotel]

And I confirm it is very hard to catch/replicate. You may want to run JMeter to achieve normal busy day behaviour.

But looking at the code, we see that it deletes first and then inserts, which does explain the possibility of a product going to OOS momentarily.

Thank you @adarshkhatri for the reply!

I agree with you about the reproduction, it is very difficult. Hence we are confirming this issue via reviewing the codebase.

Thank you for bringing this issue to our attention. If you have a potential solution, we encourage you to submit a pull request. Your contributions significantly enhance Magento Open Source for everyone. Should you need any assistance, please don't hesitate to ask!

[github-jira-sync-bot]

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