Known Issues & Workarounds

Issue #1: Authentication Popup Fatal Error

Symptom

Fatal error when authentication popup appears on frontend:

Error: Call to a member function isGlobalScopeEnabled() on null
File: vendor/magento/module-customer/view/frontend/templates/form/authentication-popup.phtml

Customer cannot log in via the popup, blocks checkout and add-to-cart for logged-in users.

Cause

Template file authentication-popup.phtml calls isGlobalScopeEnabled() on a potentially null object when the configuration helper is not properly initialized.

Root Cause: Race condition in block initialization when Full Page Cache serves partial content. The block's _toHtml() method executes before dependencies are fully injected.

Impact

• → Business: Customers cannot log in, abandoned carts increase
• → Conversion Rate: Up to 15% drop in conversion when popup login is primary method
• → Support Tickets: High volume of "cannot log in" complaints
• → Affected Users: All customers on affected versions attempting popup login

Workaround #1: Template Override

File: app/design/frontend/[Vendor]/[Theme]/Magento_Customer/templates/form/authentication-popup.phtml

<?php
/** @var \Magento\Customer\Block\Form\Login\Info $block */
$config = $block->getConfig();
$isGlobalScope = $config ? $config->isGlobalScopeEnabled() : false;
?>

<?php if ($isGlobalScope): ?>
    <!-- Safe execution with null check -->
<?php endif; ?>

References

• → GitHub Issue #39077
• → Magento Community Engineering Slack Discussion

Issue #2: Customer Module Performance with Large Datasets

Symptom

Running bin/magento setup:upgrade on stores with 500,000+ customers causes:

• • Setup scripts hang for 30+ minutes
• • PHP timeouts during upgrade
• • Recurring setup script performance degradation
• • Database queries execute slowly on customer_entity table during schema updates

Cause

Inefficient Recurring Setup Scripts: The Customer module's recurring setup scripts perform operations on the entire customer_entity table without pagination or batching.

Missing Database Indexes: Some queries in setup scripts scan full tables without proper indexing.

EAV Attribute Synchronization: Setup scripts validate and synchronize all customer EAV attributes on every upgrade, causing full table scans.

Impact

• → Performance: Customer operations 5-10x slower
• → Infrastructure Cost: Larger database servers, expensive replication
• → Backup Duration: Daily backups exceed maintenance windows
• → Development: Local database dumps too large for development environments

References

• → GitHub Issue #19469
• → Magento DevDocs: Database Performance

Issue #3: VAT Validation External API Blocking

Symptom

During checkout, billing address gets renewed on every set-payment-information call, causing VAT validation to execute multiple times:

• • 3-5 VAT validation API calls per checkout (instead of 1)
• • Address save operations take 2-5 seconds (or timeout at 10+ seconds)
• • VIES service may block/throttle requests due to excessive calls
• • Particularly severe during checkout payment step

Cause

The BeforeAddressSaveObserver makes a synchronous external API call to VIES (VAT Information Exchange System) to validate EU VAT numbers during address save. The checkout flow renews the billing address on every set-payment-information call, triggering VAT validation repeatedly for the same address.

Impact

• → User Experience: 2-5 second delays during checkout
• → Conversion Rate: 5-10% cart abandonment increase
• → Server Load: PHP-FPM workers blocked waiting for external API
• → Timeout Risk: API unavailability causes address save failures

Workaround: Disable VAT Validation

Configuration: Stores > Configuration > Customers > Customer Configuration > Create New Account Options

Set Enable Automatic Assignment to Customer Group to "No"

bin/magento config:set customer/create_account/auto_group_assign 0
bin/magento cache:flush config

References

• → GitHub Issue #28946
• → GitHub Issue #1251 (VAT validation reliability)
• → VIES API Documentation

Issue #4: Email Validation Failure for Addresses Ending with Hyphen

Symptom

Email addresses ending with a hyphen (e.g., customer@test-.com or customer@my-domain-.co.uk) are accepted during registration but cause email delivery failures:

• • Emails bounce with "domain not found" errors
• • Order confirmations never arrive
• • Password reset emails fail to send
• • Customer cannot receive any transactional emails

Cause

The idn_to_ascii() PHP function used for email validation returns FALSE (empty string) when the domain ends with a hyphen. However, Magento's validation doesn't properly check this return value.

Root Cause: RFC 952 and RFC 1123 prohibit hyphens at the end of domain labels, but Magento's validator accepts them during registration and only fails at email delivery time.

Impact

• → Email Deliverability: 1-3% of transactional emails bounce
• → Password Resets: Users with invalid emails cannot reset passwords
• → Customer Support: High volume of "didn't receive email" tickets
• → Data Quality: Polluted customer database

References

• → GitHub Issue #34318
• → GitHub Issue #25577 (Email validation via API)
• → RFC 952 - DoD Internet Host Table Specification

Issue #5: EAV Attribute Query Performance Degradation

Symptom

EAV entity load operations (products, customers, categories) consume excessive database CPU due to UNION queries:

• • UNION query to load EAV attribute values is a top database query by CPU usage
• • Each attribute backend table requires a separate UNION component
• • Product detail pages slow down under load (200-500ms per query)
• • Scales poorly with number of attributes and concurrent users

Cause

EAV architecture loads attribute values using UNION queries across multiple backend tables. Each attribute type has a separate table, and Magento UNIONs them all together. This UNION query is regenerated for every product/customer load and doesn't leverage prepared statements effectively.

Impact

• → API Performance: Slow customer endpoints (GET /V1/customers/:id)
• → Checkout Performance: Slow customer data loading during checkout
• → Admin Performance: Slow customer edit pages
• → Database Load: High number of JOIN operations

Workaround: Use Extension Attributes Instead of EAV

Don't create new EAV attributes. Instead, use extension attributes with custom tables for 10-20x better performance.

References

• → GitHub Issue #39554
• → GitHub Issue #10843 (Slow customer creation)
• → Extension Attributes Guide

Issue #6: Checkout Session Locks Blocking Requests

Symptom

During checkout, session locking causes requests to block each other:

• • session_start() calls take 500ms - 1500ms waiting for lock
• • Concurrent AJAX requests queue up instead of executing in parallel
• • Checkout progress blocks: shipping → billing → payment
• • Each step waits for previous step's session lock to release

Cause

PHP's default session mechanism uses file-based locking. When session_start() is called, PHP acquires an exclusive lock on the session file. Subsequent requests wait for the lock to be released.

Impact

• → Performance: 2-5x slower page loads with concurrent requests
• → User Experience: Perceived slowness, unresponsive UI
• → Server Load: PHP-FPM workers blocked waiting for locks
• → Scalability: Doesn't scale with increased traffic

Workaround: Redis Session Handler

Configure Redis session storage with optimistic locking for 3-5x improvement in concurrent request handling.

References

• → GitHub Issue #30383
• → GitHub Issue #34758 (Redis session locking on GET requests)
• → Magento DevDocs: Redis Session Storage

Issue #7: Multi-Store Customer Account Sharing Confusion

Symptom

Merchants expect customer accounts to be shared across all websites, but customers can't log in on different websites. Or vice versa - merchant wants separate accounts per website but customers can log in everywhere.

Cause

Configuration option customer/account_share/scope is misunderstood:

• • Global (0): Customer accounts shared across ALL websites
• • Per Website (1): Customer accounts isolated per website

Decision Matrix

References

• → Magento DevDocs: Customer Account Scope

Issue #8: Customer Group Cache with Authorization Headers

Symptom

Full Page Cache remains active even when Authorization Bearer tokens are sent, causing incorrect data to be cached and served:

• • API requests with Authorization headers get cached responses
• • Customer group-specific content (tier prices, catalog permissions) cached for wrong groups
• • Customer A with token sees cached content from Customer B's group

Cause

FPC is active even when Authorization Bearer header is present. The system doesn't recognize that authenticated API requests should bypass cache. Cache key doesn't include authorization context.

Impact

• → Pricing Errors: Customers see wrong prices
• → Business Logic Errors: Group-based catalog rules not applied
• → Customer Confusion: "Why didn't my discount apply?"
• → Revenue Impact: Potential undercharging

References

• → GitHub Issue #29775
• → GitHub Issue #38626 (FPC broken in 2.4.7)