Our app is the source of truth for inventory and hence need to do bulk sync updates pushed from our app to a Shopify store/location on a periodic basis (likely nightly). It seems like that is what inventorySetQuantities is for. You can list multiple items in the quantities parameter to do many at once. It all works great…until it doesn’t.
If there is an error, e.g. the inventory item no longer exists, the entire update fails. It does provide a list of errors, along with what I believe is the Index of the changes parameter that failed. So we could go back, remove those and reapply.
Is this the recommended method, or is there some other means we’re missing?
We also tried posting multiple changes
mutation MultipleInventoryUpdates(
$input1: InventorySetQuantitiesInput!
$input2: InventorySetQuantitiesInput!
) {
updateSet1: inventorySetQuantities(input: $input1) {
inventoryAdjustmentGroup {
id
createdAt
reason
changes {
item {
id
}
name
delta
quantityAfterChange
}
}
userErrors {
field
message
}
}
updateSet2: inventorySetQuantities(input: $input2) {
inventoryAdjustmentGroup {
id
createdAt
reason
changes {
item {
id
}
name
delta
quantityAfterChange
}
}
userErrors {
field
message
}
}
}
Interestingly, this handles errors differently. If there is an error, for one of the items, it fails silently. i.e. nothing is returned for that updateSet
. So neither is really ideal.
Any other suggestions?
I believe this is the recommended approach, unless you want to just adjust the quantities by a specific amount in which case there is another mutation for that.
You can do a list of up to 250 changes in the mutation so you would need to chunk the updates from your system to Shopify. A queue system works well here.
In terms of errors there are certain checks you could run on the products beforehand, for example checking the inventory items are still there, if the product is active at a location etc. Doing these checks and either actioning or filtering the changes with the data you get will help reduce the chances of errors.
If the mutation fails it will rollback all the changes in that single mutation so I wouldn’t run mutations in parrallel as per your example.
You could then do standard processing techniques to spilt the batch etc 
I’ve got a stock taking app so I’ve done a lot of these 
Thanks @JordanFinners . It’s probably easier to let it fail, then log and remove the errored entries and re-post (and subsequently resolve the errors).
But curious why you advise against running parallel updates? In my testing, the successful ones do post. The only issue is you don’t get any feedback on why the failed ones failed, which seems like a bug to me. It seems that update should be returned with the userErrors property populated, no?
Ah fair enough, I prefer to filter it upfront if I can to avoid extra mutations etc and not always the easiest to filter the errors on but developer preference at that point 
I’d avoid parallel updates because:
- As you mentioned you’re not getting the user errors back correctly so that would be my first concern
- You use more rate limit as running one and then a second, not in parallel will give you some time (milliseconds / seconds) for the bucket limit to refill a little Shopify API rate limits
- In my case there is a potential race condition between updates in different batches to the same product so avoids that
- Each of these mutations I believe Shopify treats as a transaction (it certainly does in AdjustQuantities) but it won’t do that across multiple mutations so you could end up with some of the ones in parallel working and others not which I think will get messy
- Personally I find it easier to debug if only one thing is being processed at a time
1 Like