Magento 2.4.7+ GraphQL Multi-Currency Bug: The Deep Dive into a Validation Headache

As e-commerce platforms evolve, the intricacies of multi-store and multi-currency configurations often reveal subtle yet critical bugs. A recent discussion on the Magento 2 GitHub repository highlights such an issue, specifically impacting GraphQL API requests in Magento versions 2.4.7 and later. This deep dive uncovers a significant currency validation error that can disrupt operations for merchants leveraging complex global setups.

The GraphQL Multi-Currency Validation Headache in Magento 2.4.7+

The core of the problem, reported as Issue #41242 by Hexmage, surfaces when a Magento 2 store is configured with multiple websites or store views, each allowing different currencies, and the global currency settings diverge from those specific store views. When a GraphQL request is made to a specific store view using the Store header and a Content-Currency header matching that store view's allowed currency, the system incorrectly throws an error: "Please correct the target currency."

Preconditions and Reproduction Steps:

This bug is confirmed on Magento 2.4.8-p5 (and reproducible on 2.4-develop), having previously worked correctly on 2.4.6-p15. To reproduce:

1. Set up a multi-website/store/storeview environment.
2. For a new website/storeview, configure its currency/options/allow, currency/options/base, and currency/options/default to a currency different from the global scope (e.g., NOK).
3. Send a GraphQL request with the appropriate Store header (your new storeview's code) and Content-Currency header (e.g., NOK).

query productDetail{
    productDetail: products(filter: {url_key: {eq: "randomstring"}}) {
        items {
            sku
            __typename
            categories {
                name
                path
                url_key
            }
        }
    }
}

Instead of the expected empty product collection, the system returns a GraphQL input error indicating an invalid target currency.

Unpacking the Root Cause: A Timing Issue

The detailed analysis by community member lbajsarowicz provided a critical breakthrough, pinpointing the exact root cause. The issue lies within the Magento\GraphQlCache\Controller\Plugin\GraphQl::beforeDispatch() method, which is active in all stock Magento installations. This plugin executes validateRequest() before processHeaders(). During this early validateRequest() call, the Magento\DirectoryGraphQl\Controller\HttpRequestValidator\CurrencyValidator checks the Content-Currency header. Crucially, at this stage, the current store context is still the default store, not the store specified in the Store header.

Consequently, the validator checks the requested currency (e.g., NOK) against the default website's allowed currencies. If NOK is not allowed globally, the validation fails prematurely, skipping the subsequent processHeaders() call that would have correctly switched the store context. The error then propagates, leading to the "Please correct the target currency" message.

Why the Regression?

This behavior is a regression introduced in recent Magento versions:

• Magento 2.4.7 (AC-821): The commit 795dd4f1bdc54783b2014d688f440cd28cc13b4f added the early validateRequest() call to the cache plugin. Before this, validation occurred later, after the store switch.
• Magento 2.4.8 (AC-11729): The commit 4d0ae3d5ce0032614ec304e147a3de6b4e8fdb75 further compounded the issue by moving processHeaders() inside the same try block, meaning any early validation failure now also prevents the store context from being correctly applied.

This change was originally intended to fix a different issue (#31336) related to store validation, highlighting the delicate balance in core platform development.

Workaround and Future Fixes

A temporary workaround involves configuring the global scope to allow all currencies that any of your store views might use. This makes the default store's allowed currency list inclusive enough to pass the early, mis-scoped validation check.

The proposed long-term solution involves modifying CurrencyValidator to validate against the store specified in the Store header (or fall back to the current store if the header is absent), ensuring the validation context is correct from the outset. The issue also highlighted a test coverage gap, suggesting the need for specific API-functional tests to prevent similar regressions.

This detailed community insight underscores the importance of thorough testing and the invaluable contributions of the Magento developer community in identifying and resolving complex issues that impact the platform's stability and functionality, especially for businesses relying on sophisticated multi-store and multi-currency setups.