Session getLastRealOrder may return wrong order when duplicate incrementIds are used

[Allcharles]

Preconditions and environment

• Magento version: 2.4.8-p1
• Anything else that would help a developer reproduce the bug

Given a system which has managed to create two orders for two different stores, with the same increment id in the sales_order table; the loadByIncrementId function in Order.php can return the wrong order. In my scenario, getLastRealOrder from app/code/Magento/Checkout/Model/Session.php would return the wrong order.

In my case, because there was no DB constraint preventing this data from existing, and parts of the magento code base assume that the incrementId will be unique, my system would attempt to update the wrong order at certain points.

I do not know how to replicate the scenario which caused by DB to get into such a state, but this does appear to be a small gap in the system. Assuming this gap is not for supporting an old behaviour of the system, it would make sense to either update the code base to close the possibility, or update the constraint check on the DB.

DB Constraint on the sales_order table:

Related Code:

1. loadByIncrementId with bad assumption that increment_id can uniquely identify an order:

   magento2/app/code/Magento/Sales/Model/Order.php

   Line 560 in a8cf637

   public function loadByIncrementId($incrementId)

2. Example of this function being used which affected my system:

   magento2/app/code/Magento/Checkout/Model/Session.php

   Line 556 in a8cf637

   $this->_order->loadByIncrementId($orderId);

Assuming the number of users who could possibly be affected by this issue is low, I have marked the priority as S4.

Steps to reproduce

1. Create two orders in the sales_order table using different store IDs, and the same incrementId
2. Call loadByIncrementId

Expected result

1. loadByIncrementId should return a list of orders

Actual result

1. loadByIncrementId selects an order if multiple match

Additional information

No response

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”.

[m2-assistant]

Hi @Allcharles. Thank you for your report.
To speed up processing of this issue, make sure that the issue is reproducible on the vanilla Magento instance following Steps to reproduce.

• For more details, review the Magento Contributor Assistant documentation.
• Add a comment to assign the issue: @magento I am working on this
• To learn more about issue processing workflow, refer to the Code Contributions.

---

Join Magento Community Engineering Slack and ask your questions in #github channel.
⚠️ According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting.
🕙 You can find the schedule on the Magento Community Calendar page.
📞 The triage of issues happens in the queue order. If you want to speed up the delivery of your contribution, join the Community Contributions Triage session to discuss the appropriate ticket.