[BUG] Legacy `collectionAddProductsV2` will add to the shared source instead of adding to the collection

[Soufiane_Ghzal]

Steps to reproduce

• Have an app to create a app-shared-source with a product p-A.
• Create a collection c-A and attach the shared source.
• Create a collection c-B and attach the shared source.
• With the app, use the mutation collectionAddProductsV2 to one or more products p-B to collection c-A.
• Create a third collection c-C and attach the shared source

Expected result

• c-A has the shared source (with p-A) + another non-shared source with with p-B
• c-B has the shared source. Only product is p-A
• c-C has the shared source. Only product is p-A

Actual result

• c-A has the shared source with p-A and p-B
• c-B has the shared source with p-A
• c-C has the shared source with p-A and p-B

Bug 1

Adding a product to a collection actually updated the source and effectively affects all collections using the source. This is materialized with c-C now having p-B despite the app requested it to be added only to collection c-A.

Bug 2

At this point the shared source is affected by bug 1 and has two products instead of one. However c-B is only showing a single product (see screenshot below). I suspect it to be some kind of caching issue.

Additional resources

Both screenshot below have been captured after reloading the browser at least 5 minutes after the steps to reproduce have been applied

c-A screenshot

c-B screenshot

the source data queried from the graphql api

Please note that it has two additional products added by the mutation

        {
          "id": "gid://shopify/CollectionConditionsSource/25498058983",
          "title": "test shared source multi collection",
          "targetType": "PRODUCTS",
          "products": {
            "nodes": [
              {
                "id": "gid://shopify/Product/8868004724967",
                "title": "The Videographer Snowboard"
              },
              {
                "id": "gid://shopify/Product/8868004757735",
                "title": "The Archived Snowboard"
              },
              {
                "id": "gid://shopify/Product/9519119433959",
                "title": "test product"
              }
            ],
          }
        },

c-B products from the graphql API

Please note that it has only one product despite using a source with three products:

   "collection": {
      "title": "c-B",
      "products": {
        "edges": [
          {
            "node": {
              "title": "The Videographer Snowboard"
            },
            "cursor": "eyJsYXN0X2lkIjo4ODY4MDA0NzI0OTY3LCJsYXN0X3ZhbHVlIjoiMCJ9"
          }
        ],
        "pageInfo": {
          "hasNextPage": false
        }
      }
    }
  },

Why is it critical?

Adding products to a collection will add to the source instead which will spread to all collections using that source. It breaks the contract of adding to just one collection, and it break the announced backward compatibility of the mutation collectionAddProductsV2 which can now transitively add products to many collection at once.

As for bug 2 - it’s quite obvious. It’s not showing the right set of products.

[Alan_G]

Hey @Soufiane_Ghzal - I think this is the flip side of what you’re seeing on your other thread there. When a collection has a single source, the legacy collection-grained mutation targets that source, so if it’s your shareable one, the add lands there and fans out to every collection linked to it. That’s expected behaviour for the legacy path, but I definitely get it’s not ideal. The fix should be the same as the other thread: use collectionUpdate with sourcesToCreate to give c-A its own collection-scoped source, then sourcesToUpdate for future adds.

On the c-B product count mismatch, if you’re still seeing it after the source shows all three products, could you share the shop domain and the c-B collection ID? Happy to take a look at that one separately.

Let me know if I can help out further.

[Soufiane_Ghzal]

Hi @Alan_G thank you for following up. I was told that 2026-07 is a non breaking release, I’m surprised to hear that this is the expected behavior.

We’ll migrate everything as quickly as possible and cross finger we’re not affected in production.

---

For the collection c-B that was not updated, that’s on a demo store: quickstart-552af987.myshopify.com and the collection id is 471637197031.

Not a problem to fix on the store itself as it’s the sandbox I used to understand the problems, but it might hide a deeper bug.

Cheers

[Alan_G]

Hey @Soufiane_Ghzal - thanks for following up - definitely fair. Just confirming, the non-breaking piece holds in the sense that a collection backed only by a shareable source is a 2026-07-only shape, so nothing that worked before changed from what I can tell.

That said, I dug a bit further on our end and the legacy add landing on the shared source is something I want to take a closer look into. The migration to collectionUpdate with your own collection-scoped source is still the right move regardless, but I’ll loop back once I hear more. Thanks for the c-B details too, I’ll take a look at that one separately.

[Soufiane_Ghzal]

@Alan_G

so nothing that worked before changed from what I can tell.

The issue is that we have no control on what users and other apps do to collections created by an app that still use the old API.

[Alan_G]

Hey @Soufiane_Ghzal - fair point, and I definitely get that you can’t control what other callers do to collections your app creates. That’s useful feedback and I’m passing it along with the rest of this.

On c-B, just confirming this isn’t caching. I took a look on our end and the source is showing all three products but that collection only has the one membership row, so the add updated the shared source without carrying through to the collection that was already linked to it. I’m going to look into this internally along with the broader question of the legacy mutation writing into a shareable source in the first place. I can’t guarantee a timeline, but we’ll keep you in the loop.

In the meantime, the collectionUpdate path with your own collection-scoped source is still the safest way to keep adds isolated to one collection.

[Soufiane_Ghzal]

@Alan_G

you can’t control what other callers do to collections your app creates

@Alan_G Thank you, fyi I already passed this feedback early July, directly to Diana though. It’s not a new issue, and I don’t doubt that the dev team at Shopify has already considered it already when they worked on this migration.

@Alan_G

In the meantime, the collectionUpdate path with your own collection-scoped source is still the safest way to keep adds isolated to one collection.

That’s what we’re doing gradually but even migrating to the new system is complex. We have to consider cases when they added more sources, that have inclusions, exclusions etc… We can’t simply migrate blindly as it has direct consequences on their stores.