Magento 2 FPC Glitch: Why Logged-in Customers See Guest Prices and How to Fix It

Accurate pricing is the bedrock of any successful e-commerce store. For Magento 2 merchants, especially those leveraging customer group-specific pricing, ensuring that the correct price is displayed to the right customer at all times is paramount. However, a recent GitHub issue (#40474) brought to light a critical bug affecting Magento 2.4.8-p3 that could lead to logged-in customers seeing guest user prices on Product Detail Pages (PDP) and Product Listing Pages (PLP) due to an interaction with the Full Page Cache (FPC).

The Problem: Guest Prices Persisting for Logged-in Users

The issue describes a scenario where, after a customer with a special group price logs into a Magento 2.4.8-p3 store running in production mode with FPC enabled, the PDP/PLP continues to display the guest user's price. The correct customer group price only appears much later, typically when the product is added to the cart. This creates a confusing and potentially frustrating experience for customers, undermining trust and impacting conversion rates.

The root cause, as meticulously investigated by the issue author (ioweb-gr), lies in how Magento's FPC identifies and serves cached pages. The expectation is that FPC should vary content based on factors like the X-Magento-Vary cookie, ensuring that different customer segments (e.g., guests vs. logged-in users with specific group prices) receive appropriately cached content. However, the investigation revealed a misconfiguration in the dependency injection (DI) preferences:

• The Magento\Framework\App\PageCache\IdentifierInterface preference was pointing to Magento\PageCache\Model\App\Request\Http\IdentifierForSave.
• This IdentifierForSave class, when FPC hits, was found to be empty, leading to an incorrect cache key being used.
• Consequently, the FPC failed to read the vary cookie correctly, resulting in cached guest prices being served to logged-in users.

The author noted that this specific preference (IdentifierForSave) was a relatively recent introduction, suggesting it might be a regression from earlier Magento versions.

The Proposed Solution: A DI Preference Adjustment

Fortunately, the issue author also provided a direct workaround by adjusting the DI preference in the module-page-cache's etc/di.xml file. The fix involves changing the preference for Magento\Framework\App\PageCache\IdentifierInterface to point to the more general Magento\Framework\App\PageCache\Identifier class instead of IdentifierForSave.

Code Snippet: Applying the Fix in di.xml

Here's the proposed change:

Index: etc/di.xml
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/etc/di.xml b/etc/di.xml
--- a/etc/di.xml
+++ b/etc/di.xml        (date 1769703123582)
@@ -44,5 +44,5 @@
     
     
     
-    
+    
 

This change effectively re-routes the FPC identifier logic to use the standard identifier, which correctly considers the HTTP context and vary cookie, ensuring that customer group prices are displayed immediately after login.

Community Response and Implications

While the issue provided a clear diagnosis and solution, the community interaction saw a bot assist with standard processing, and crucially, an Adobe Commerce engineer (engcom-Bravo) reported an inability to reproduce the issue on the latest 2.4-develop instance. This suggests a few possibilities:

• The bug might be specific to Magento 2.4.8-p3 and potentially resolved in later development branches or upcoming releases.
• The reproduction steps might be sensitive to specific environment configurations not present in the vanilla 2.4-develop instance used for testing.

For merchants and developers currently on Magento 2.4.8-p3 and experiencing this pricing discrepancy, the provided di.xml fix offers a highly actionable workaround. However, it's always recommended to thoroughly test such changes in a staging environment before deploying to production. If you are planning an upgrade or are already on a newer version, verifying if this bug persists in your specific environment is key.

At Shopping Mover, we understand the complexities of Magento migrations and ongoing maintenance. Issues like this highlight the importance of meticulous testing and staying informed about community-driven solutions. While core bugs are addressed by Adobe, proactive monitoring and applying targeted fixes can maintain store integrity and customer satisfaction.