I got AI to write this obviously. I had to break up long commands for the post to accept it. Sorry about that.
Hoping someone has seen this, or can tell me what else drives the admin’s bundle UI.
What I did
I had a few hundred shared-stock groups set up as Shopify-native bundles: one variant holding the real unit stock, and each pack-size variant registered as a bundle of N × that base. It worked, but marketplace orders imported from another channel were arriving split into component lines, and I wanted the order pages to show the listing that was actually sold.
So I unwound them. For each parent variant I called product Variant Relationship Bulk Update, passing that parent’s own component variant ids in product Variant Relationships To Remove. Every call came back with userErrors: []. That covered 1,281 variants across 602 products, almost all on the same day.
What I expected
The variants go back to being ordinary products — their own stock, their own quantity field, editable like anything else.
What actually happened
The API agrees it worked. The admin doesn’t.
On the affected variants the admin still behaves as though they’re bundles:
- The variant page shows “Available — Not tracked” where the inventory field should be
- The Available dropdown says “Quantity is set by the product with the lowest inventory that is set up to track inventory”
- Bulk Edit doesn’t appear when I tick variants on the product page
- Adjustment history is empty
Oddly, the product page works — if I pick a location there, I can edit the quantity for the exact same variant. It’s only the variant-level views that are stuck.
What the API says
Every one of the 1,281 variants:
requires Components : false
product Variant Components : []
product. has Variants That Requires Components : false
product. combined Listing Role : null
inventoryItem. tracked : true
inventory Levels : 1, at my single active location, with a real quantity
And the legacy REST fields, in case the admin still reads those:
inventory_management : “shopify”
fulfillment_service : “manual”
inventory_policy : “deny”
I also scanned the whole catalogue — 23,061 variants — and exactly zero come back with requiresComponents: true. There isn’t a bundle left in the store by any measure I can query.
The part I find hardest to explain: I have a product that renders perfectly in admin whose API profile is identical, field for field, to one that’s stuck. Same status, same option structure, same tracking, same inventory levels, same legacy fields, combinedListingRole: null on both. I cannot find a single data difference between a good one and a bad one.
Things I’ve already ruled out
- Browser cache — reproduced in a second browse
- Propagation delay — it’s been well over 24 hours
- Needing a write to “touch” the product — I’ve since edited products, which bumps updatedAt. The stuckproducts now have more recent updatedAt values than the one that displays fine. Didn’t help.
- Combined listings — combinedListingRole is null throughout.
- Inactive locations — I have two inactive locations left over from old setups, but nothing is stocked at either, and the levels are all at the one active location
- The tracking flag itself — it’s on, and inventory_management is “shopify”
My actual questions
- Is there some other field or internal flag that drives whether the admin renders a variant as a bundle? Everything I know to check says “not a bundle”.
- Has anyone found a way to force the admin to re-read this, short of contacting support?
- Is this just a known lag on bundle removal at scale, and does it eventually resolve on its own? If so, roughly how long?
I’m on API version 2025-10, single active location, and the removals were done via the Admin GraphQL API rather than throughany bundles app UI — I wonder whether that’s the relevant difference, since the app that originally created the relationships is the same one that removed them.
Happy to share more detail if it helps.