Hello Shopify team…
While making GraphQL calls to retrieve DraftOrders I am receiving this internal server error from Shopify:
message:
“Internal error. Looks like something went wrong on our end.
Request ID: 5443f743-c559-4d55-a5d2-5053b4b3b634-1762706629 (include this in support requests).”
extensions:
{
:requestId=>“5443f743-c559-4d55-a5d2-5053b4b3b634-1762706629”,
:code=>“INTERNAL_SERVER_ERROR”}
}
I looked up your request ID and found the issue - the query is timing out because it’s fetching a massive amount of nested data. You’re requesting 50 draft orders with dozens of nested fields, plus up to 100 line items per draft order (each with 50+ fields). The database query hit the timeout limit and got killed.
The query is pulling full billing addresses, shipping addresses, all the money sets (presentment + shop), tax lines, discount allocations, fulfillment service details with nested locations, and more. That’s way too much data for a single request.
A few options to fix this:
Option 1: Reduce the fields you’re requesting. Only ask for what you actually need. E.g do you really need latitude/longitude on every address, or all the nested fulfillment service location details?
Option 2: If you need bulk exports of draft order data, use the Bulk Operations API instead. It’s designed for large data exports without timeouts.
Option 3: Paginate your line items separately instead of requesting 100 per draft order inline. Query draft orders with basic fields first, then fetch detailed line item data in follow-up queries for the ones you need.
The timeout is happening at the database level, so trimming your field selection is the fastest fix. Let me know if you need help with any of the above three options and I’ll be more than happy to!
Hi @Donal-Shopify thanks for researching and providing the root cause. Unfortunately we cannot reduce the amount of requested fields. The customers want a LOT of data.
We did not use the bulk APIs because most people didn’t have that volume of data, thus we haven’t really run into this issue before. I believe we will likely need to add in the pagination options and maybe reduce the number of line items.
Thanks for the context, your proposed approach makes sense. You can keep all the fields your customers need but just spread the data across multiple requests.
Let me know if you have any specific questions about implementing pagination, or if you see any similar errors with the updated requests and I’ll be happy to take a look!