The productVariants endpoint is behaving in an inconsistent way, consider the following queries involving collection 462611775740 and collection 448235798780
462611775740 is a manual collection
448235798780 is an automated collection with rules:
- Products must match all conditions
- Compare-at price is greater than $0
Query #1: Request ID 2fdc64b1-dba1-43a0-9812-44362ac52ba2-1772569378
{
productVariants (first: 250, query: "collection:462611775740") {
edges {
node {
id
price
compareAtPrice
}
}
}
}
And if you count up the nodes returned, you get 64
Query #2: Request ID 3a2e62d6-a0af-497f-be88-c87b0fdece2b-1772569595
{
productVariants (first: 250, query: "collection:462611775740 AND collection:448235798780") {
edges {
node {
id
price
compareAtPrice
}
}
}
}
And that gives you an empty list. In other words, the API is telling me that there are not variants that are in both the first and second collection.
Query #3: Request ID 09242b56-9a9a-42d7-a654-90ee41e91155-1772569697
{
productVariants (first: 250, query: "collection:462611775740 AND -collection:448235798780") {
edges {
node {
id
price
compareAtPrice
}
}
}
}
This gives back 30 edges instead of the expected 64. If if I look at the exact items returned, it only contains the items that have a compare at price of literally 0 (as opposed to a null/blank compare at price)
Of course, this is illogical. Since collection 1 has 64 items and collection 1 and collection 2 should have no overlap, query #3 should also return 64 edges.
(Also note that I can swap the “-” operator for "NOT " and the result is the same)
The shop ID is 25197379683
Basically, it looks like in the context of query #3, there is a bug that leads to items with a null compare at price being considered “Greater than $0” which is not consistent or correct.