Has anybody encountered issues with productVariantsCount returning the wrong count?
Its returning 111, my store definitely doesn’t have 111 variants. So I requested productVariants and only received 51 back, which is correct. So what’s going on here?
To test a bit further I just created a fresh dev store using the generated test data which contains 26 variants, ran the request for productVariantsCount and it has returned 26!
So there is something up with the store returning 111. I also remove some variants, based off removing an option for ‘The Complete Snowboard’ so it dropped to 15 variants. Ran the request again and I’m still getting 111 so something is wrong here.
@Liam-Shopify is this something you could look into? The store is stock-monitor-dev.myshopify.com
Hi Luke - our product team is looking into this inconsistency. Will update here when I have more info.
Thanks Liam, appreciate it!
hey Luke, there the shop was in an inconsistent state and has been fixed. Please try again and let me know if you run into further inconsistencies.
Hey @Liam-Shopify @teddyhwang,
I was migrating to the new GraphQL productVariantsCount, but it seems to be returning incorrect results.
My script iterates over our existing customers and compares the variant counts from the old API method, the new GraphQL, and the existing variants in our database.
I found incorrect results with the new method in 15 out of 100 stores. The old API is consistent with our database, but the GraphQL method returns inaccurate results.
Thanks @Merchbees - I mentioned in another thread that we’re working on ensuring these counts are accurate.
I’m curious for both you and @Luke - whats your use case for productVariantsCount?
We use productVariantsCount query to set the queue of background job.
count >= 5k, set queue name as highcount <= 5k, set queue name as lowHey @Tim-Shopify,
Thank you so much for fixing the productsCount cap. We use product count, variant count, and collection count in our pricing model. When customers install the app, we let them choose a plan based on these numbers. For a smoother onboarding experience, we need these values right at the beginning, immediately after installation.
Our Low Stock Alert app uses both variant and product count.
Our Collection Manager app uses product and collection count.
It would be great if you could remove the cap for the unfiltered version of the collectionsCount as well.
My app plans are based on SKU/Variant count so I use this information to inform the merchant of which plan they will require as well as any additional costs for over usage.
We’re seeing the same issue as well on some stores (e.g. 40,756 real count vs 41,468 coming from the GraphQL productVariantsCount query).
Same use case as Merchbees and Luke where subscription plans are based on total variants in Shopify (we do this check at the very beginning before merchants activate a subscription).
We’ve shipped some improvements and there shouldn’t be any more inconsistencies between REST and GraphQL. Please let me know if you’re still seeing the issue.