Swatches are not crossed out if salable quantity is 0

[chequille]

Preconditions (*)

1. Magento 2,4,3

Steps to reproduce (*)

1. Make a configurable product with f.e. 3 options
2. 
3. Place an order for this product with one of the options so salable quantity is 0 after the order is placed. In the sample of the screenshot it is the product with option 0.1l and qty 3
4. After this order, in backend salable qty is 0 for the 0.1l product
5. 
6. But in frontend, the swatch for 0.1l is still selectable and not crossed out as it should.
7. 

Expected result (*)

1. The swatch option 0.1l should be crossed and not selectable anymore as it worked in Mangeot 2.3.x

Actual result (*)

1. The swatch option 0.1l is not crossed and still seleactable.

---

Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.

• [ ] 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[bot]]

Hi @chequille. Thank you for your report. To help us process this issue please make sure that you provided the following information:

• Summary of the issue
• Information on your environment
• Steps to reproduce
• Expected and actual results

Please make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce. To deploy vanilla Magento instance on our environment, please, add a comment to the issue:

@magento give me 2.4-develop instance - upcoming 2.4.x release

For more details, please, review the Magento Contributor Assistant documentation.

Please, 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.

:warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.

:clock10: You can find the schedule on the Magento Community Calendar page.

:telephone_receiver: The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, please join the Community Contributions Triage session to discuss the appropriate ticket.

:movie_camera: You can find the recording of the previous Community Contributions Triage on the Magento Youtube Channel

:pencil2: Feel free to post questions/proposals/feedback related to the Community Contributions Triage process to the corresponding Slack Channel

[chequille]

@magento give me 2.4-develop instance - upcoming 2.4.x release

[magento-deployment-service[bot]]

Hi @chequille. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @chequille, here is your Magento Instance: https://58a36aeb0861e83a0218a18f7bd766c9-2-4-develop.instances.magento-community.engineering Admin access: https://58a36aeb0861e83a0218a18f7bd766c9-2-4-develop.instances.magento-community.engineering/admin_44d9 Login: 1b46bee6 Password: 78994276973b

[chequille]

Reproduced on 2.4.develop instance. Ordered 100 Chaz Kangeroo Hoodie XS black but in frontend XS is still selectable

If I select it and add it to cart, than it is crossed and the error message comes up that I have to selet an option. But the crossed XS must be there as soon as the product page is launched.

On my site (using the release 2.4.3) the swatch remains not crossed even if I selected and added it to the cart. This is the only difference to the Magento Instance.

Please correct this as fast as possible.

[m2-assistant[bot]]

Hi @krishprakash. 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: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).

  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 4. Verify that the issue is reproducible on 2.4-develop branch

  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - 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.

[magento-engcom-team]

:white_check_mark: Confirmed by @krishprakash Thank you for verifying the issue. Based on the provided information internal tickets MC-43089 were created

Issue Available: @krishprakash, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

[chequille]

HI Guys, saw that you put this on P2 I would like to have this at least P1

I am paying since more than 9 month now for a VServer to be able to switch to 2.4.x and cannot because of this bug. Please consider to put this on highest priority as it is a mandatory feature and many other installation wil have this problem as well. I would like to get a patch as soon as you found the problem. I definetely cannot wait another 3 or more months for the next release.

BR Chequille

[Kannakiraj123]

@magento assign this to me

[Kannakiraj123]

@magento I am working on this

[Kannakiraj123]

@magento give me 2.4-develop instance

[magento-deployment-service[bot]]

Hi @Kannakiraj123. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @Kannakiraj123, here is your Magento Instance: https://58a36aeb0861e83a0218a18f7bd766c9-2-4-develop.instances.magento-community.engineering Admin access: https://58a36aeb0861e83a0218a18f7bd766c9-2-4-develop.instances.magento-community.engineering/admin_1c3a Login: d5285bfa Password: 528d19642c1e

[github-jira-sync-bot]

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

[m2-assistant[bot]]

:white_check_mark: Confirmed by @engcom-November. Thank you for verifying the issue.
Issue Available: @engcom-November, You will be automatically unassigned. Contributors/Maintainers can claim this issue to continue. To reclaim and continue work, reassign the ticket to yourself.

[dphilipps]

I too have been waiting patiently for this fix and very disappointed to find such a crucial feature is still not working properly. What is the point of maintaining a salable_quantity if the store still shows unsalable products as in stock?!!

I've spent many hours going around in circles on this issue testing on the 2.4.3 release (and latest branch) but I have established the following facts:

• When all indexers are set to 'Scheduled' and cron is NOT running, the store correctly crosses out unsaleable products when salable_qty becomes 0, and they stay that way - it works.
• After a product is completely sold out and correctly crossed out, invalidating the indexes via 'Index Management' in admin will cause the swatch to revert to showing the product as salable again (i.e. no longer crossed out)
• Likewise, running /php bin/magento indexer:reindex from the command line will revert all unsalable products so they appear in stock on the front end of the store. Running cron with scheduled indexes normally has a similar effect.
• After purchasing all salable stock for a product, the stock_status column is automatically set to 0 in the cataloginventory_stock_status table. The view inventory_stock_1 reflects this accordingly in the 'is_salable' column.
• Immediately after reindex, invalidation, or running cron, this value (is_salable) reverts to 1 for any test cases that were working previously.

The bottom line is it appears at least one of the major issues is with the re-indexing of the salable status. I believe it may be reverting the salable status of a product immediately after it is sold out before you can navigate back to the product page to check it is working. I hope this is of some help to fixing and verifying this feature as working.

[engcom-Alfa]

We also have the ticket description helps to reproduce the issue.

[vseager]

This issue is still reproducible on 2.4.3 for both configurable and simple products.

[dphilipps]

Hi @chequille Have you checked that consumers are running, specifically inventory.reservations.updateSalabilityStatus

This consumer is responsible for changing the salability status after a product is completely sold out. And because it runs as an asynchronous process, there is sometimes a delay in the sold out product being crossed out on the front-end. Without the consumer running, it does not become crossed out at all.

There is a different issue I have noticed where reindexing will revert the salability status of products so they are no longer crossed out. However, the bug has been closed so I'll try and get it reopened: https://github.com/magento/magento2/issues/34127

[chequille]

Hi @dphilipps , must be honest, I do not know how to check. As well, as I do not need it currently, I don't have cronjobs running. But I know, that this did all work in Magento 2.3.x wihtout problem.

My solution currently is to make the changes in Magento/InventoryIndexer/Model/IsProductSalable.php as describe in https://github.com/magento/magento2/pull/33885

Fact as I see it is, that as I said before isSaleable() and isSalable() methods do not car about salable quantity. They just look at stock quantity and return true if it is not 0.

The change in the class IsProductSalable changes this and it works for me at the moment. THe only thing I did have to do is to make my product view site and the calatolg view site not cachable.

WIth this changes, "add to cart" button and as well the crossed options of a configurable product are correct as they should.

As for the moment, I can live with the fact of not caching the page, but there should be a fix in the future in any case, as it is a shame that this issue makes that much problems.

My opinion!

Regards, Chequille

[m2-assistant[bot]]

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: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).

  Details

  If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.

• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.

• [ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• [ ] 4. Verify that the issue is reproducible on 2.4-develop branch

  Details

  - Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
  - 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]

@magento give me 2.4-develop instance

[magento-deployment-service[bot]]

Hi @engcom-Bravo. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @engcom-Bravo, here is your Magento Instance: https://14d2636ee35bf2b4b20c8e848a0f7b71.instances.magento-community.engineering Admin access: https://14d2636ee35bf2b4b20c8e848a0f7b71.instances.magento-community.engineering/admin_361e Login: 8f58bb60 Password: 926e6b435f2b

[engcom-Bravo]

Hi @chequille,

Thank you for reporting and collaboration. Verified the issue on Magento 2.4-develop branch but could not able to reproduce the issue. Kindly refer the screenshots.

1.Created a Configurable product with 3 options.

2.Order placed with qty 3(color-gray).

3.After placing the order the quantity is 0.

4.In frontend we are not able to see that grey color swatch.

Let us Know we miss anything.

Thanks.

[mysil2]

@engcom-Bravo This needs to be run with MSI. Quantity should still stay at 3 when order is in pending/processing state, but Salable quantity will go from 3 to 0, and the bug will still show the swatch. When order is shipped/complete, then quantity is set to 0 and swatch is not shown.

[chequille]

I agree to mysil. This happen when using MSI which is standard as I know. Am I wrong?

[engcom-Bravo]

@magento give me 2.4-develop instance

[magento-deployment-service[bot]]

Hi @engcom-Bravo. Thank you for your request. I'm working on Magento instance for you.

[magento-deployment-service[bot]]

Hi @engcom-Bravo, here is your Magento Instance: https://14d2636ee35bf2b4b20c8e848a0f7b71.instances.magento-community.engineering Admin access: https://14d2636ee35bf2b4b20c8e848a0f7b71.instances.magento-community.engineering/admin_3e37 Login: ced839d4 Password: 08806a1cb62e