Critical Magento 2.4.7-p10 Bug: Unpacking the Silent Bundle Product Quantity Doubling Issue

E-commerce platforms are the backbone of modern retail, and their stability, especially during the crucial checkout phase, is paramount. A seamless customer journey translates directly into sales and customer loyalty. However, a recently identified critical regression in Magento Open Source and Adobe Commerce 2.4.7-p10 has sent ripples through the developer community, threatening to disrupt this delicate balance. Issue #41039, reported on GitHub, details a severe bug that can silently double the quantity of bundle, configurable, and grouped products in the cart, leading to frustrating checkout failures and abandoned carts. As experts in Magento migrations and platform optimization at Shopping Mover, we understand the profound impact such issues can have on your business.

The Silent Threat: Unseen Quantity Duplication in Your Magento Cart

Imagine this scenario: A customer meticulously selects a beautifully curated bundle product, adding it to their cart with a quantity of '1'. They proceed to checkout, confidently entering their shipping address. Unbeknownst to them, during this seemingly innocuous step—or any other action that triggers a quote save, like re-saving the quote after total collection—the bundle product's quantity in their cart mysteriously doubles to '2'.

This isn't merely a visual glitch. The Magento system, now operating under false pretenses, recalculates all bundle selection requirements based on this inflated parent quantity. For instance, if a bundle originally required 60 units of a sub-item, it now demands 120. If this new, doubled quantity exceeds the available stock for any component, the system throws a fatal validation error: "The requested qty is not available." The entire checkout process grinds to a halt, leaving the customer confused, frustrated, and likely to abandon their purchase. This S1 severity bug, as classified by the community, signifies a critical impact on core functionality, demanding immediate attention and a robust workaround.

Unveiling the Root Cause: A Regression Born from ACSD-46869

The detailed bug report by CreamDevelopment meticulously traces the origin of this insidious issue back to a specific change introduced by Adobe's quality patch ACSD-46869. This patch, originally designed to address a separate bug where bundle option changes weren't persisted without a corresponding quantity change, inadvertently removed a crucial safeguard within the Magento core.

Prior to ACSD-46869, the system's logic in Magento\Quote\Model\Quote\Item\CartItemPersister::save() was more cautious. It would only invoke Quote::updateItem() if the item's quantity had genuinely changed (if ($currentItem->getQty() !== $buyRequestData->getQty())). This conditional check prevented unnecessary updates to unchanged cart items. However, the patch removed this guard, leading to updateItem() being unconditionally called for any existing item whenever the quote is saved, regardless of whether its quantity or options had actually been modified.

The Deeper Dive: How updateItem() and resetCount Fail for Bundles

The plot thickens within Quote::updateItem(). This method is designed to prevent double-counting by calling $buyRequest->setResetCount(true). This flag is then used by Quote\Item\Processor::prepare() to reset the item's quantity to 0 before Item::addQty() runs, but only under a specific condition: if ($item->getId() == $request->getId()).

Here lies the critical flaw for bundle products: The buyRequest object constructed for bundle products by Quote\Item\CartItemOptionsProcessor::getBuyRequest() (which, in turn, uses Bundle\Model\CartItemProcessor::convertToBuyRequest()) never sets an id on the returned DataObject. It typically only carries essential data like bundle_option, bundle_option_qty, and qty. Consequently, the crucial $item->getId() == $request->getId() check within Quote\Item\Processor::prepare() always fails for bundle products.

Without a matching ID, the resetCount mechanism is bypassed. When addQty() is called, it adds the buyRequest's quantity (which is the bundle's original quantity, e.g., 1) on top of the item's already existing quantity (also 1). The result? A silent, insidious doubling of the bundle product's quantity to 2.

This gap in CartItemOptionsProcessor and Bundle\Model\CartItemProcessor was harmless before ACSD-46869 because updateItem() was rarely invoked for an unchanged item. Once the guard was removed, this vulnerability became exposed with every quote save, making it a critical issue for merchants running affected Magento 2.4.7-p10 instances.

Suggested Fixes and Immediate Workarounds for Developers

The GitHub issue proposes two primary solutions:

• Set the Item ID: Modify Quote\Item\CartItemOptionsProcessor::getBuyRequest() (and/or product-type-specific convertToBuyRequest() implementations) to explicitly set an ID matching the quote item ID on the returned DataObject. This would allow the existing resetCount guard to function as intended.
• Restore Conditional Update: Reintroduce a narrower condition in CartItemPersister::save() that only calls updateItem() when a quantity or option change has genuinely occurred, rather than unconditionally on every save.

For immediate relief, a practical workaround involves implementing a before plugin on Quote::updateItem(). This plugin would intercept the call and ensure that the $buyRequest object has its ID set to match the $itemId if it's currently missing. This allows Magento's internal resetCount guard to correctly identify and reset the quantity before adding it, preventing the doubling effect.

// Example of a conceptual before plugin (simplified)
namespace YourVendor\YourModule\Plugin;

use Magento\Quote\Model\Quote;
use Magento\Framework\DataObject;

class FixBundleQtyDoubling
{
    public function beforeUpdateItem(
        Quote $subject,
        $itemId,
        DataObject $buyRequest
    ) {
        // Only apply if the ID is missing, which is the case for affected bundle products
        if (!$buyRequest->getId()) {
            $buyRequest->setId($itemId);
        }
        return [$itemId, $buyRequest];
    }
}

Note: This is a conceptual example. Actual implementation requires proper module setup, di.xml configuration, and thorough testing.

Shopping Mover's Perspective: Proactive Platform Health and Migration Expertise

At Shopping Mover, we emphasize that such critical bugs underscore the importance of continuous platform monitoring, rigorous testing, and expert development practices. For merchants considering or undergoing a Magento migration, identifying and addressing these types of regressions is non-negotiable. A successful migration isn't just about moving data; it's about ensuring a stable, performant, and bug-free environment post-launch.

If you're running Magento Open Source or Adobe Commerce 2.4.7-p10, we strongly advise you to investigate your system for this issue, especially if you utilize bundle, configurable, or grouped products. Proactive identification and implementation of the workaround can save you from significant revenue loss and customer dissatisfaction.

Our team of Magento migration experts at shopping-mover.com is equipped to help you navigate complex platform updates, identify potential vulnerabilities, and implement robust solutions. Whether you're upgrading, migrating, or simply seeking to optimize your current Magento instance, ensuring the integrity of your checkout process is our top priority.

Conclusion

The silent doubling of bundle product quantities in Magento 2.4.7-p10 is a critical bug that can severely impact your e-commerce operations. Understanding its root cause—a regression from ACSD-46869 affecting how quote items are persisted and updated—is the first step towards mitigation. By implementing the suggested workarounds and maintaining a vigilant approach to platform health, merchants can safeguard their checkout process and ensure a smooth, reliable experience for their customers. Don't let silent bugs undermine your sales; stay informed, stay proactive, and partner with experts who can keep your Magento store running flawlessly.