Request ID: bac30b0a-58a6-4201-b26b-6d5179e2ed52-1773755789 (include this in support requests).
I am using the NPM package shopify-api-node
{
"message": "Internal error. Looks like something went wrong on our end.",
"timestamp": "2026-03-17T13:56:56.659Z",
"error_processing_input": "RequestError",
"code": "ERR_GOT_REQUEST_ERROR",
"request_id": "bac30b0a-58a6-4201-b26b-6d5179e2ed52-1773755789",
"stack_trace": [
"at Request.<anonymous> (/app/node_modules/got/dist/source/as-promise/index.js:113:42)",
"at maybeError (/app/node_modules/shopify-api-node/index.js:299:13)",
"at Request.<anonymous> (/app/node_modules/got/dist/source/as-promise/index.js:87:42)",
"at process.processTicksAndRejections (node:internal/process/task_queues:103:5)"
],
"timings": {
"start": 1773755789153,
"socket": 1773755789154,
"lookup": 1773755789154,
"connect": 1773755789154,
"secureConnect": 1773755789154,
"upload": 1773755789154,
"response": 1773755816655,
"end": 1773755816655,
"error": null,
"abort": null,
"phases": {
"wait": 1,
"dns": 0,
"tcp": 0,
"tls": 0,
"request": 0,
"firstByte": 27501,
"download": 0,
"total": 27502
}
},
"extensions": {
"requestId": "bac30b0a-58a6-4201-b26b-6d5179e2ed52-1773755789",
"code": "INTERNAL_SERVER_ERROR"
},
"locations": null,
"path": null
}
Hey @JordanQuartermain 
I looked into the request ID you provided and can see this was a server-side database timeout, not something caused by your code or the library you’re using.
The query was paginating through priceList.prices with first: 250, and the combination of nested variant/product field lookups on that many records caused an internal query to exceed its execution time limit. A transient cache layer issue on our side compounded the problem.
Two things worth trying. First, reduce the page size from first: 250 to something smaller like first: 50. The official docs examples use first: 10 for this query, and 250 generates a lot of internal lookups per page, especially when you’re pulling nested variant and product fields for each price. That should reduce the per-request database load. Second, add retry logic with backoff for 5xx responses, since transient timeouts like this can happen on large datasets.
A few quick questions to help me understand the scope of this. Is this happening consistently or was it a one-off? Roughly how many prices are in this price list? And is this a new integration or something that was working before and recently started failing? If it’s persistent even at smaller page sizes, I can raise it with the relevant team for a closer look!
Hey @Donal-Shopify ! Thanks for your reply 
I have added some advanced retry logic on my end. It goes a little something like this…
I have reduced the page size to 200. If there’s an error response that isn’t throttled and similar to what I have described, I’ll reduce the pagination limit further and wait 5 seconds before re-attempting. This will be done up to 10 times before I throw my own error. Hopefully that will fix this particular issue.
This error appears to affect a single merchant using my app. The merchant does have many priceLists and each priceList has 90,000 items approx. I haven’t encountered this error before, but it is inconsistent with this particular merchant. Sometimes I can fetch the 90,000 items just fine, other times I can’t.
Thanks for the additional context! Good to hear the retry logic is in place, that’s the right approach for transient errors like this. A few things worth adjusting though, given the scale you’re describing.
Looking at the query from the request ID you shared, the main thing I’d flag is the product { id tags title } nested inside each variant. For a price list with 90,000 items, that means resolving the full product object on every single price entry, even when many variants belong to the same parent product. At first: 250 that’s a lot of work per page and what’s pushing the request past the database timeout threshold.
Two things I’d try. First, strip the query down to just the pricing and variant ID fields, something like this:
query ($priceListId: ID!, $cursor: String) {
priceList(id: $priceListId) {
prices(first: 25, after: $cursor) {
nodes {
price { amount }
compareAtPrice { amount }
originType
variant { id }
}
pageInfo {
hasNextPage
endCursor
}
}
}
}
The doc examples for this query use first: 10, so starting at 25 and scaling from there gives you some room. You can then map variant IDs back to products in a separate, lighter query where you control the batch size. That way the price list pagination isn’t doubling as a product data fetch.
Second, for recurring syncs of the full 90K items, GraphQL Bulk Operations might be worth testing. You’d submit a bulkOperationRunQuery with your priceList.prices query and Shopify processes it asynchronously, returning a JSONL file with all the results. This avoids the per-request timeout window entirely. It’s a bigger change than adjusting page size, but for 90K items it would be more reliable than paginating through hundreds of pages.
If you’re still seeing timeouts at first: 25 with just the variant ID, share a fresh request ID and I’ll dig in further. Cheers!
I’ve also decided to write 2 functions to run queries in parallel. One from reversed and one from non-reversed. When they each fetch 55% of the total, I return and filter out duplicates. This seems to be reliable and makes up for the slower pagination too.
1 Like