My app currently sends a bulk query to get stores’ product catalog.
It works very well but for some stores it doesn’t.
After several hours, the bulk operation is cancelled. I receive the cancellation webhook but it doesn’t provide any additional information (no error code).
Anyone from Shopify’s Team would be able to give me more information about what’s going on?
Example of a bulk which didn’t work: “gid://shopify/BulkOperation/6652642820246”
For the stores where this is not working are you seeing any similarities? eg: large catalogs or complex object graphs, or unusual/ legacy data that makes resolving your query slower.
What other info do you get when you query the bulkOperation? eg: objectCount, fileSize
If you remove non‑essential fields from the bulk query and avoid deeply nested or heavy connections, does it run as expected on stores it previously failed on?
Your mutation itself is valid (I validated a normalized version against the latest Admin schema on my side), so this is not a schema/structure bug—it’s about how heavy the query is in practice on large catalogs.
Bulk operations have strict practical limits: the docs say there’s a maximum of five connections per query, and your query hits that limit (productVariants , plus media/metafields on both the variant and the product). Combined with the depth of metafield references and large data volumes, Shopify’s backend ends up considering the operation “stalled” and automatically cancels it.
That’s why your tests behave the way they do: querying media only on variants works, and querying media only on products works, but querying media on both at once results in status: "CANCELED" with errorCode: null tipping it over.
To make this reliable, you’ll want to split the work into multiple lighter bulk operations rather than one “everything at once” query. A common pattern is: one bulk for core product/variant data (no media), one bulk for product media keyed by product ID, and one bulk for variant media keyed by variant ID. After that you can then join these JSONL outputs in your own processing pipeline.
My query has five connections, but it should be valid as the doc says “Maximum of five total connections in the query.”.
Plus, my query respects the depth mentioned in the documentation “Maximum of two levels deep for nested connections.”.
So I guess it is more a matter of data volume for some stores (my query works for a majority stores), but the documentation doesn’t mention any restriction about data volume.
I’ll try to see if I can split my query in several queries, but it is a non trivial work to do on my side .
I understand the frustration here @guifo - it appears you’re hitting a performance/throughput limit, not a schema or structural violation. The bulk engine isn’t rejecting your query upfront; it accepts and runs it.
But for shops where the product catalog + media + metafields + references are very large, the operation progresses so slowly that it’s treated as stalled and auto‑canceled. That’s why it works for the majority of stores but not for the largest/most complex ones, and why you see CANCELED with errorCode: null instead of FAILED with a specific error.
I’ll look into improving the documentation with regard to data volume so devs can easily troubleshoot when they experience similar issues.