Critical Magento 2.4.6-p8 Bug: Configurable Products Persist in Categories with $0 Price

Unpacking a Critical Magento 2.4.6-p8 Bug: Configurable Product Visibility After Stock Depletion

As e-commerce migration experts at Shopping Mover, we constantly monitor the Magento community for critical issues that can impact merchant operations and development efforts. A recent GitHub issue (#40739) highlights a significant bug in Magento 2.4.6-p8 that affects configurable product visibility and pricing, especially problematic for headless implementations utilizing GraphQL.

This S1 severity bug, reported on Magento Open Source and Adobe Commerce 2.4.6-p8, presents a perplexing scenario where configurable products defy stock settings, remaining visible in categories even after all their child products are no longer salable. This not only creates a poor customer experience but also introduces data inconsistencies, particularly for modern headless architectures.

The Core Problem: Configurable Products Lingering in Categories with Misleading Prices

The reported issue describes a scenario where, despite all child products of a configurable product becoming unsalable (out of stock) after a purchase, the parent configurable product inexplicably remains visible in its assigned category. This occurs even when the 'Display out of stock product' setting is explicitly set to 'NO' in the Magento configuration – a fundamental setting designed to prevent such occurrences.

The problem is exacerbated by two critical side effects:

1. The configurable product displays with an 'Out of Stock' status, directly contradicting the store's configuration to hide such items. This can lead to customer frustration and a perception of poor inventory management.
2. For headless sites using GraphQL, the products query returns the configurable product, but its price_range attribute shows a misleading $0 value. This can severely impact front-end rendering, filtering, and overall user experience, potentially leading to abandoned carts or incorrect product displays.

Technical Context and Preconditions: A Deep Dive

Understanding the environment in which this bug manifests is crucial for both reproduction and potential mitigation. The issue was reported under specific, yet common, Magento 2.4.6-p8 configurations:

• Magento Version: 2.4.6-p8 (Adobe Commerce or Open Source)
• MSI (Multi-Source Inventory) Installed: MSI is Magento's advanced inventory management system. Its presence is key, as it manages stock quantities across multiple sources and determines product salability.
• Stock and Sources Setup: Proper configuration of inventory sources and stock assignments is assumed, indicating a standard MSI setup.
• RabbitMQ Correctly Setup: RabbitMQ is Magento's message broker, essential for asynchronous operations, including inventory updates. The bug specifically mentions waiting for the inventory.reservations.updateSalabilityStatus consumer to finish, highlighting the asynchronous nature of stock updates in MSI.
• Elasticsearch Correctly Setup: Elasticsearch powers Magento's catalog search. Its correct setup ensures that catalog data is indexed and searchable, making the persistence of out-of-stock products in categories even more perplexing.
• 'Display out of stock product' -> NO: This is the most critical setting. It explicitly instructs Magento not to show products that are out of stock. The bug's existence directly violates this core configuration.
• All Indexers are Green: Confirms that all Magento indexers are up-to-date, ruling out indexing issues as the primary cause.

Steps to Reproduce the Glitch

The author, adarshkhatri, provided clear, actionable steps to reproduce this S1 severity bug, making it easier for developers to confirm and debug:

1. Setup: Ensure your Magento 2.4.6-p8 environment meets the preconditions listed above, especially the 'Display out of stock product' setting being 'NO'.
2. Product Creation: Create a configurable product (e.g., 'my-config') with a single child product (e.g., 'my-config-red'). Configure the child product with 1 quantity and set backorders to 'No'. Both products should have their visibility set to 'catalog, search' and be assigned to a category.
3. Initial Check: Navigate to the category page on the frontend. You should observe both the configurable product and its child product listed.
4. Simulate Purchase: Add the child product to the cart and complete the checkout process. This action depletes the child product's stock.
5. Wait for Consumer: Allow time for the inventory.reservations.updateSalabilityStatus consumer to finish running. This consumer is responsible for updating product salability statuses based on inventory changes.
6. Observe the Category Page: Revisit the category page on the frontend.

Expected Result: Both the configurable product and its child product should be gone from the category page, adhering to the 'Display out of stock product -> NO' setting.

Actual Result: Only the child product disappears. The configurable product stubbornly remains in the category, displaying an 'Out of Stock' status and, critically for headless implementations, returning a price_range of $0 via GraphQL queries.

                    "price_range": {
                        "minimum_price": {
                            "final_price": {
                                "value": 0
                            }
                        }
                    },

Impact on Merchants and Developers

This bug carries significant implications for both store owners and the development teams supporting them:

• Customer Experience Degradation: Customers seeing 'Out of Stock' products when they shouldn't, or products with a confusing '$0' price, can lead to frustration, abandoned sessions, and a loss of trust in the store's accuracy.
• Misleading Data for Headless Frontends: For e-commerce businesses leveraging GraphQL for their headless Magento sites, this bug directly feeds incorrect data. A '$0' price can break front-end logic, filtering, and even lead to display errors or misinterpretations of product availability. Developers will need to implement complex front-end workarounds to filter out these erroneous products, adding unnecessary development overhead.
• Operational Inefficiencies: Merchants might spend time investigating why certain products are still visible or why their analytics show strange price points for unavailable items.
• Debugging Challenges: Identifying the root cause of such a discrepancy can be time-consuming for developers, especially when core settings appear to be ignored.

Why This Matters for E-commerce Migrations

At Shopping Mover, we understand that migrating to a new Magento 2 version or platform is a complex undertaking. Bugs like #40739 underscore the critical importance of thorough testing and expert oversight during any migration project:

• Pre-Migration Assessment: Identifying known bugs in target Magento versions (like 2.4.6-p8) is crucial during the planning phase. This allows for proactive strategies, whether it's waiting for a patch, planning custom fixes, or adjusting migration timelines.
• Post-Migration Validation: Comprehensive UAT (User Acceptance Testing) is non-negotiable. This bug highlights that even seemingly fundamental settings can be compromised, requiring specific test cases to validate product visibility and pricing across all product types and stock scenarios.
• Headless Migration Risks: For businesses migrating to a headless Magento architecture, this bug is particularly insidious. The reliance on GraphQL for product data means that front-end applications are directly exposed to these data inconsistencies. Shopping Mover's expertise in integrating Magento with various front-end technologies helps anticipate and mitigate such integration challenges.
• Custom Development Needs: Until an official patch is released, merchants might need custom development to implement temporary workarounds, such as custom GraphQL resolvers or front-end filtering logic. Our team can assist in developing robust, temporary solutions that don't compromise future upgrades.

Navigating the Bug: What You Can Do

While an official fix from Magento is awaited, here are some considerations:

• Monitor the GitHub Issue: Keep a close eye on #40739 for updates, potential workarounds from the community, or official patch releases.
• Front-end Filtering (for Headless): If you're running a headless site, implement robust front-end logic to filter out configurable products with a price_range of $0 or an 'Out of Stock' status, even if they appear in the GraphQL query results. This is a temporary measure to prevent poor customer experience.
• Thorough Testing: If you are on or planning to upgrade to Magento 2.4.6-p8, ensure your testing protocols include specific scenarios for configurable product stock depletion and category visibility.
• Consult Experts: For complex scenarios or during a migration, engaging with Magento experts like Shopping Mover can help you navigate such bugs, implement effective workarounds, and ensure your e-commerce platform remains stable and performs optimally.

Conclusion

The configurable product visibility and pricing bug in Magento 2.4.6-p8 is a stark reminder that even mature e-commerce platforms can have critical issues. For merchants, it underscores the importance of vigilant monitoring and robust testing. For developers, it highlights the complexities of inventory management with MSI and the nuances of GraphQL integrations. At Shopping Mover, we are committed to helping businesses navigate these challenges, ensuring smooth migrations and optimized e-commerce operations. Stay informed, stay proactive, and don't let critical bugs derail your online success.