GraphQl Content-Currency exception when default config differs from website/storeview. #41242

Preconditions and environment

• 2.4.8-p5
• This was working fine on magento 2.4.6-p15
• Issue seems to only occur when the global currency differs from the storeview specific one.
• Can be worked around by setting the global config to allow all Currencies, your Storeviews allow.

Steps to reproduce

1. Create a second website, store and storeview.
2. Change currency/options/allow, currency/options/base and currency/options/default to a value different from the global scope for this new website, e.g. NOK.
3. Send any graphql request to the server with a Store header = [your new storeview storecode] and Content-Currency header = NOK.

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

Expected result

Expected result is an empty product collection as no product with this url exists.

{
    "data": {
        "productDetail": {
            "items": []
        }
    }
}

Actual result

Actual result is an error that the currency send as a header is not allowed.

{
    "errors": [
        {
            "message": "Please correct the target currency",
            "extensions": {
                "category": "graphql-input"
            }
        }
    ]
}

Additional information

After some debugging I concluded that the Magento\DirectoryGraphQl\Controller\HttpRequestValidator\CurrencyValidator class is validating the Content-Currency header against both the global scope and the storeview scope. So the core issue seems to be that the Store header is not applied early enough for the Content-Currency to be properly validated.

Release note

No response

Triage and priority

• Severity: S0 - Affects critical data or functionality and leaves users without workaround.
• Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
• Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
• Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
• Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.