Magento 2.4.7-p10 Sales Order Grid Date Filter Failure with Braintree: A Deep Dive

Unraveling the Magento 2.4.7-p10 Sales Order Grid Date Filter Bug with Braintree

The intricate world of e-commerce platforms like Magento often presents unique challenges, especially when integrating third-party payment gateways. A recent GitHub issue (Issue #40841) highlights a persistent problem affecting Magento Open Source and Adobe Commerce installations running version 2.4.7-p10 with Braintree modules enabled. This bug prevents merchants and administrators from filtering orders by purchase date in the Sales Order Grid, leading to a critical SQL error.

The Core Problem: Ambiguous 'created_at' Column

The issue manifests as a SQLSTATE[23000]: Integrity constraint violation: 1052 Column 'created_at' in WHERE is ambiguous error. This occurs specifically when a user attempts to apply a date filter (e.g., purchase date or order creation date) within the Magento Admin Sales > Orders grid. The root cause lies within the PayPal\Braintree\Plugin\SalesOrderGridPlugin.php class.

This Braintree plugin is designed to enrich the Sales Order Grid collection by joining additional tables, specifically braintree_transaction_details and, crucially, sales_order. Both the main grid table (sales_order_grid, aliased as main_table) and the joined sales_order table contain a created_at column. When the date filter is applied, the generated SQL query's WHERE clause references created_at without specifying which table it belongs to, causing ambiguity for the database (MariaDB in this case).

Environment and Reproducibility

The bug has been confirmed on Magento 2.4.7-p10, running PHP 8.3, MariaDB 10.11, OpenSearch 2.19, Valkey 8.1, and Varnish 8. The steps to reproduce are straightforward:

1. Install Magento 2.4.7-p10.
2. Enable the Braintree modules (e.g., PayPal_Braintree).
3. Log in to Magento Admin.
4. Navigate to Sales > Orders.
5. Attempt to filter orders by purchase date.

The expected outcome is a correctly loaded grid showing filtered orders. However, the actual result is a failed grid request and a logged SQL exception.

Technical Deep Dive into the SQL Error

The problematic SQL query generated by Magento, when Braintree is enabled and a date filter is applied, looks something like this:

SELECT `main_table`.*,
       `braintree_transaction_details`.`transaction_source`,
       `sales_order`.`dispute_status`
FROM `sales_order_grid` AS `main_table`
LEFT JOIN `braintree_transaction_details`
    ON braintree_transaction_details.order_id = main_table.entity_id
LEFT JOIN `sales_order`
    ON sales_order.entity_id = main_table.entity_id
WHERE (((`created_at` >= '2026-05-28 07:00:00')))
  AND (((`created_at` <= '2026-05-29 06:59:59')))
ORDER BY main_table.created_at DESC
LIMIT 20

Notice the WHERE clause: WHERE (((`created_at` >= '...'))...). The created_at column here is unqualified. The fix, as outlined in the issue, requires qualifying this column with the main table alias:

WHERE (((`main_table`.`created_at` >= '2026-05-28 07:00:00')))
  AND (((`main_table`.`created_at` <= '2026-05-29 06:59:59')))

This simple qualification resolves the ambiguity for the database, allowing the query to execute successfully.

Impact and Broader Context for Magento Users

While this issue is marked with a Severity S2 (affecting non-critical functionality but requiring a workaround), its impact on merchants and administrators can be significant. The inability to filter orders by date directly impedes essential administrative tasks, such as order management, reporting, and customer service inquiries. For businesses relying on Braintree for payments, this bug necessitates either a temporary workaround or a patch to restore full functionality.

It's noteworthy that similar "ambiguous column" issues related to the Sales Order Grid have been reported and closed in previous Magento versions (e.g., #38818, #39144, #40351). The recurrence of this problem in 2.4.7-p10 suggests a need for more robust validation or a standardized approach to column qualification within Magento's core and its official extensions, especially those that modify collection queries like payment gateway integrations.

For developers and system integrators, understanding this specific interaction between the Braintree plugin and Magento's core collection logic is crucial for debugging and maintaining stable e-commerce environments. As Shopping Mover, we emphasize the importance of thorough testing, especially after updates or when enabling new extensions, to catch such integration-specific issues before they impact live operations.