Hi !
I’m trying to query the sales of a shop via bulk operation but I get an internal server error probably because the number of objects is too important.
Here is the query :
bulkOperationRunQuery(
query:“{orders(query:“updated_at:>=‘2026-01-26T14:35:47.074Z’ AND updated_at:<‘2026-01-26T14:35:57.000Z’”,sortKey:UPDATED_AT){edges{node{id agreements{edges{node{id happenedAt reason…on ReturnAgreement{return{id}}sales{edges{node{id actionType lineType quantity…on ProductSale{lineItem{id}}}}}}}}}}}}”
) {
bulkOperation {
id
errorCode
},
userErrors {
code
field
message
}
}
As you see, I’m only querying the data for 1 minute, but I can’t make it work with the bulk operation. I have a fallback mecanism on classic graphql queries for which I’m forced to use pagination, which defeats the whole point of using the bulk operation API, and it looks like this problem has been going on for a long time and has been reported several times, do we have any updates on this?
And is there anything I could do on my side to prevent this?
This order has 120 elements in the “sales” attribute.
Hey @Noe_Morvillers! The problem is that the SalesAgreement interface doesn’t implement Node, which is a requirement for bulk operation connections. It may work for orders with low cardinality, but once the agreements or nested sales connection needs to paginate (like your order with 120 sales), it fails.
Unfortunately there’s no fix on your side - the only workaround is falling back to regular paginated queries when bulk operations fail on specific orders which I know that defeats the purpose.
There’s been feedback from the community asking for SalesAgreement to implement Node. I’ll raise this thread with the relevant team again to add another data point, but I can’t promise any timeline on when or if that would happen. I’ll update here if I hear anything back - thanks for raising this again!
@Donal-Shopify Hey, this has been an issue for a while, and it’s also clearly causing issues on Shopify’s development team’s end as well - they can’t implement proper validation without messing up already “half-working” workflows (people can mass-sync orders that don’t have to paginate over agreements/sales).
Can we bump up the priority of implementing Node in the SalesAgreement interface? Synchronizing agreements/sales on a per-order basis is not viable for high-volume stores. However, it’s incredibly important to be able to synchronize them somehow.
Can we have any feedback on this?
Thanks for following up!
The related April thread was addressed by reverting the stricter bulk operation validation that started rejecting agreements queries up front. That let those bulk queries be accepted again, but it did not change the underlying limitation here. Bulk operations can still fail when orders > agreements > sales needs nested pagination on high-cardinality agreement or sales data.
For now, the practical workaround is still to bulk sync the order IDs or simpler order data first, then fetch agreements.sales with regular paginated Admin GraphQL for the orders that need that detail. I know that is not ideal for high-volume syncs. There are internal discussions around the right long-term path here, including Node support for these types, but I do not have a timeline or confirmed implementation plan to share yet.