You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Describe the bug
Bug When One Product in Stock. No order can be placed. After investigating the issue, it's observed that no problems occur with MSI + Adyen or with Hyva theme + MSI. However, the issue arises when the compatibility module is involved. Specifically, when attempting to add a configurable product with limited stock (e.g., 2 items), the shipping methods do not appear on the checkout page. Interestingly, if the pre-selected shipping method is not changed, the issue does not occur.
In the code, two calls are made to CartItemPersister to collect BuyRequestData using the line: $buyRequestData = $this->cartItemOptionProcessor->getBuyRequest($productType, $item);
This BuyRequestData can either be a float value or an object. In the first request, it's a float, so no exception is thrown. However, in the second request, it becomes an object. When the system proceeds to update the quote item with the following logic: if (is_object($buyRequestData)) { /** Update item product options */ if ($quote->getIsActive()) { $item = $quote->updateItem($itemId, $buyRequestData); } }
While updating the quote item, the logic in Quote.php tries to add more products to the quote, same amount as already added to the cart. Since there are no additional items available in stock, this triggers an exception. $resultItem = $this->addProduct($product, $buyRequest);
My observation is that since the configuration is only needed to populate data in the payment block, it may be sufficient to fetch only the specific configurations required for those blocks, rather than retrieving all configurations.
To Reproduce
Steps to reproduce the behavior:
Make sure MSI is enabled and set up correctly
Make sure you have a configurable product with at least one option that has 1 in stock (note: it will also happen with a larger stock, but 1 might be easier to test)
Add the configurable option to your cart and make sure you add all items in stock to the cart
Go to the checkout
Fill in the form and change the country
If you keep the country as it is, the same issue will happen when selecting a (different) shipping method
Expected behavior
It's possible to change the country
It's possible to select a shipping method
Actual behavior
When changing the country or selecting a shipping method, an error is shown that the requested quantity is not available
No shipping methods are available anymore and it's impossible for customers to place an order
Magento version
2.4.7
Plugin version
1.1.0
Additional context
This issue doesn't happen for simple products
This issue doesn't happen if Adyen is removed (disabling through the admin doesn't solve it)
I've done quite some research and debugging here and noticed that the issue comes from the Adyen module fetching all the configuration for the checkout in the payment block's constructor (\Adyen\Hyva\Block\PaymentMethod). This results in the additional options being loaded in \Magento\Checkout\Model\DefaultConfigProvider::getQuoteItemData(), which on itself results in the buy request being an object in \Magento\Quote\Model\Quote\Item\CartItemPersister::save() on line 75. Because this is an object, it will update the order item and not just set the new quantity. Through some more steps we will get to \Magento\Quote\Model\Quote\Item::addQy() where the current item quantity is increased with the given quantity (which is also the current quantity).
Since the configuration is only needed for filling the data in the payment block, it might be enough to just fetch the specific configuration that is needed in these blocks and not fetch all the configurations.
The text was updated successfully, but these errors were encountered:
hi @mbernabeu thanks for the comment and the nice details that give a good head start.
Also thank you for this suggestions "Since the configuration is only needed for filling the data in the payment block, it might be enough to just fetch the specific configuration that is needed in these blocks and not fetch all the configurations."
I am thinking though that this configuration is needed in a situation when we have a one step hyva checkout enabled, in which case it is possible to select a payment method before anything else is done with the checkout including selecting the shipping method. This is probably the reason behind the current implementation.
I have a feeling that the important thing to clarify is why would the $cartItem have product options attached in the faulty case, and not in other cases.
Describe the bug
Bug When One Product in Stock. No order can be placed. After investigating the issue, it's observed that no problems occur with MSI + Adyen or with Hyva theme + MSI. However, the issue arises when the compatibility module is involved. Specifically, when attempting to add a configurable product with limited stock (e.g., 2 items), the shipping methods do not appear on the checkout page. Interestingly, if the pre-selected shipping method is not changed, the issue does not occur.
In the code, two calls are made to CartItemPersister to collect
BuyRequestData
using the line:$buyRequestData = $this->cartItemOptionProcessor->getBuyRequest($productType, $item);
This
BuyRequestData
can either be a float value or an object. In the first request, it's a float, so no exception is thrown. However, in the second request, it becomes an object. When the system proceeds to update the quote item with the following logic:if (is_object($buyRequestData)) { /** Update item product options */ if ($quote->getIsActive()) { $item = $quote->updateItem($itemId, $buyRequestData); } }
While updating the quote item, the logic in Quote.php tries to add more products to the quote, same amount as already added to the cart. Since there are no additional items available in stock, this triggers an exception.
$resultItem = $this->addProduct($product, $buyRequest);
My observation is that since the configuration is only needed to populate data in the payment block, it may be sufficient to fetch only the specific configurations required for those blocks, rather than retrieving all configurations.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
Actual behavior
Magento version
2.4.7
Plugin version
1.1.0
Additional context
The text was updated successfully, but these errors were encountered: