Avoid loading the order collection twice for customer orders GraphQL query

[thai2301]

Description

Fetching customer { orders { items { items } } } via GraphQL loads the sales order collection from the database twice:

1. Magento\SalesGraphQl\Model\Resolver\CustomerOrders::resolve() loads the customer's orders (orderRepository->getList()) and passes each fully-loaded OrderInterface down as $value['model'].
2. When the nested order items are resolved, Magento\SalesGraphQl\Model\OrderItem\DataProvider::fetchOrders() re-queries orderRepository->getList() for the very same orders, only to read each item's currency / store id / discount data.

The item resolvers already have the loaded parent order in hand, so there is no need to reload it. This adds an addOrder(OrderInterface $order) method to the data provider; the resolvers that own the order model (OrderItems, Invoice\InvoiceItems, CreditMemo\CreditMemoItems) register it, and fetchOrders() starts from those provided orders and queries the repository only for order ids that were not provided.

The Resolver\OrderItem path (nested child/bundle items, which only holds a parent order item, not the order) continues to work through that fallback, so behavior is unchanged for callers that don't provide an order. Keying is by sales_order.entity_id (the sales_order_item.order_id foreign key target), matching the previous lookup.

Related Issue

Fixes #40966

Manual testing scenarios

1. Enable DB query logging.
2. As a customer, run:

query {
    customer {
        orders {
            items {
                id
                items { id }
            }
        }
    }
}

3. Before this change: the sales_order collection is loaded twice (once by CustomerOrders, once by OrderItem\DataProvider::fetchOrders).
4. After this change: it is loaded once; the order-item data provider reuses the orders already loaded by the orders resolver. Invoice/credit-memo item queries are unaffected (they also reuse their already-loaded order), and nested child-item resolution still works via the not-provided fallback.

Questions or comments

None.

Contribution checklist

• Pull request has a meaningful description of its purpose
• All existing and new tests pass
• Static tests pass
• Ensured backward compatibility

[m2-assistant]

Hi @thai2301. Thank you for your contribution!
Here are some useful tips on how you can test your changes using Magento test environment.
❗ Automated tests can be triggered manually with an appropriate comment:

• @magento run all tests - run or re-run all required tests against the PR changes
• @magento run <test-build(s)> - run or re-run specific test build(s)
  For example: @magento run Unit Tests

<test-build(s)> is a comma-separated list of build names.

Allowed build names are:

1. Database Compare
2. Functional Tests CE
3. Functional Tests EE
4. Functional Tests B2B
5. Integration Tests
6. Magento Health Index
7. Sample Data Tests CE
8. Sample Data Tests EE
9. Sample Data Tests B2B
10. Static Tests
11. Unit Tests
12. WebAPI Tests
13. Semantic Version Checker

You can find more information about the builds here
ℹ️ Run only required test builds during development. Run all test builds before sending your pull request for review.

---

For more details, review the Code Contributions documentation.
Join Magento Community Engineering Slack and ask your questions in #github channel.

[thai2301]

@magento run all tests

[thai2301]

@magento run all tests

[thai2301]

@magento run all tests