App A creates a shareable source and attaches it to Collection A
App B pushes products to Collection A using the legacy mutation collectionAddProductsV2
Expected Results
Products pushed by App B are added to Collection A in a non-shareable-source.
Actual results
Products pushed by App B will not get added to Collection A
Notes
Note that the same behavior will occur even if Collection A has non-shareable sources, as long as it has at least one shareable-source from another collection (anywhere in the list, first of not).
Just confirming, this one is working as intended rather than a bug, just in my understanding, though I definitely get it’s not super ideal given the migration path. Since collectionAddProductsV2 is collection-grained (no source ID), it has no safe way to decide where the products should land once a collection has a source owned by another app or more than one source. Rather than guess (or write into another app’s source, which is the issue you flagged back in July), it now rejects up front.
You should be seeing job: null with a userErrors entry - either “Source is not owned by this app” or “Can’t add products to a collection with multiple sources” depending on where the shareable source sits. Let me know if you’re getting an empty userErrors array instead, as that’d be worth a closer look on our end.
The path forward for App B is to own its own collection-scoped source on that collection via collectionUpdate:
mutation AddOwnSource($collectionId: ID!, $selections: [CollectionInclusionProductSelectionInput!]!) {
collectionUpdate(collection: {
id: $collectionId,
sourcesToCreate: [{
source: {
title: "App B picks",
targetType: PRODUCTS,
inclusion: { selections: $selections }
}
}]
}) {
collection { id sources { __typename id title app { id } } }
userErrors { field message }
}
}
Then use sourcesToUpdate with inclusion.selectionsToAdd on that source for subsequent pushes (keeping the 10 sources per collection limit in mind):
Hope this makes sense - let me know if I can clarify anything further here!
A sensible default would be to put them in the first non shareable source or create one for that purpose if none exists.
Your proposed fix would be ideal, but you may not realize the complexity it adds in a real use case, especially when you’re dealing with large volume of data and a small mistake can screw the whole collection and has a direct impact on merchant’s sales.