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: https://github.com/magento/magento2/blob/a8cf637b1016ecbbe1c547c910f3db862c04f4fa/app/code/Magento/Sales/Model/Order.php#L560
2. Example of this function being used which affected my system: https://github.com/magento/magento2/blob/a8cf637b1016ecbbe1c547c910f3db862c04f4fa/app/code/Magento/Checkout/Model/Session.php#L556

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.
• [x] Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.

[m2-assistant[bot]]

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. :warning: According to the Magento Contribution requirements, all issues must go through the Community Contributions Triage process. Community Contributions Triage is a public meeting. :clock10: You can find the schedule on the Magento Community Calendar page. :telephone_receiver: 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.

[m2-assistant[bot]]

Hi @engcom-Hotel. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

• [ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
• [ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue.
• [ ] 3. Add Area: XXXXX label to the ticket, indicating the functional areas it may be related to.
• [ ] 4. Verify that the issue is reproducible on 2.4-develop branch
  Details

  - If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
• [ ] 5. Add label Issue: Confirmed once verification is complete.
• [ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

[engcom-Hotel]

Hello @Allcharles,

Thanks for reporting this and for working with us.

I reviewed the codebase and the sales_order table and it seems if the increment_id appears for different store_id values the issue might occurs.

To help us investigate further, could you explain the exact scenario where the same increment_id appears for different store_id values? It’s possible a third‑party extension is responsible. Could you also try reproducing this on branch 2.4-develop and tell us whether it still happens?

Thanks

[engcom-Hotel]

Hello @Allcharles,

Have you got a chance to look into the above comment?

Thank you