Hi,
We have been intermittently receiving graphQLErrors, and recently this has gotten particularly bad and consistent for one of our clients.
We do retry this with exponential backoff and utilize paging, if this is an issue with our query we’d like to know more about how to craft this, but we’d also like to know more about why this failed for this specific client and not others which we were still able to pull data from today, using the same query and successfully receiving a sizeable amount of data.
It would also be greatly appreciated if these errors could contain more information (assuming this is something that could have been resolved on our side), currently all we have is:
{“message”:“Internal error. Looks like something went wrong on our end.”,“locations”:[{“line”:3,“column”:9}],“extensions”:{“code”:“INTERNAL_SERVER_ERROR”},“path”:[“orders”]}
Here are some sample requestId’s from attempts that errored few minutes ago:
- 96bda4da-c783-4ddb-9866-30f8ef11029f-1780409515
- 468c8b15-4f75-4598-a4ec-d840389762ea-1780409539
- 1787ae34-ca71-4abd-8d35-04f2a307221e-1780409566
- 53129c56-2ab3-42e1-a288-67670a221b2e-1780409583
- 7e9d4990-be5e-4e9d-aecf-9d1c79fa8492-1780409602
- 47fce2e7-fba2-4336-a7be-746d561702db-1780409621
If there’s any further information from the requests I can provide or the query we are using please let me know
Thank you
Hey @Ryan_Scott
thanks for reaching out and for the context here.
Looking into the logs for these request IDs and 500 responses, it looks like the orders query is timing out at the database for this specific client rather than a problem with the query itself.
Here’s what’s happening: you’re filtering on created_at, but the results come back sorted by a different field (the default sort, or whatever sortKey you have set). When a client’s order history is large enough, the database can’t use a single index to handle both the date filter and the sort at once, so it ends up scanning a huge number of rows and hits an internal time limit. That surfaces as the INTERNAL_SERVER_ERROR. Your smaller clients never trip it because there aren’t enough rows to slow the scan down.
The fix is to match your sortKey to the field you’re filtering on. Since you’re filtering created_at, set sortKey: CREATED_AT:
query getOrders($cursor: String) {
orders(
first: 50
after: $cursor
sortKey: CREATED_AT
query: "created_at:>='2025-02-01' created_at:<='2025-02-28' (financial_status:paid OR financial_status:partially_paid OR financial_status:pending)"
) {
edges {
cursor
node {
id
name
createdAt
displayFinancialStatus
totalPriceSet { shopMoney { amount currencyCode } }
}
}
pageInfo { hasNextPage endCursor }
}
}
That lets the same index serve both the filter and the sort, and the query comes back in milliseconds instead of timing out. There’s more info on this in our docs here: https://shopify.dev/docs/api/usage/search-syntax#using-created_at-in-a-range-query
One more option: if you’re pulling a large amount of data, the bulk operations API could be something to explore as well: Perform bulk operations with the GraphQL Admin API
Hope this helps!