TL;DR
In a draft-order checkout, any in-session change to a cart-transform’s ExpandOperation output for an expanded cart line — relative to the output produced at draft-order creation in the admin — corrupts the order. The corruption surfaces either as a silent cart-wipe in the UI (useCartLines() → [], cost.totalAmount.current → 0) or as a failure to complete the order even when the cart still visually appears intact. The visible-wipe variant is accompanied by a setter on types-UnauthenticatedErrorModalPayload in the negotiate cycle.
The same code paths work correctly on standard (non-draft-order) online-store checkouts, and worked correctly on draft-order checkouts until recently — likely today (2026-05-27).
Why we believe this is a recent Shopify-side change
The draft-order admin started rendering the result of the cart-transform ExpandOperation inline today — expansion children are now visible in the draft-order line-item list. This is new behavior and points at a recent change to how cart-transforms are evaluated and persisted for draft orders. The corruption described below appeared in the same window.
Repro
-
Create a draft order containing real products plus a cart line whose merchandise the cart-transform expands via
ExpandOperation. The cart-transform runs at draft-order creation and produces output A.
-
Send the draft order to checkout. In-session, cause the cart-transform to emit any
ExpandOperationfor that expanded line that differs from A. The re-evaluation can be driven by anything that’s a cart-transform input — a UI-extension attribute write, a payment method change, an address change, etc.
→ Either of the following happens:
-
Visible wipe: within seconds,
useCartLines()updates to[],cost.totalAmount.currentresets to 0, and the checkout total displays as $0. A setter ontypes-UnauthenticatedErrorModalPayloadfires during the negotiate cycle in the same stack as the wipe. -
Silent corruption: the cart visually appears intact, but attempting to complete the order fails.
Expected
The cart should remain intact and the order should be completable across in-session cart-transform output changes. Cart-transforms are documented as reactive to their inputs (cart attributes, payment method, address, etc.) — there is no documented contract that re-emitting a different ExpandOperation for a previously-expanded line on a draft-order checkout is destructive.
Environment
-
Shopify Plus
-
Extensions:
cart_transform(purchase.cart-transform.run) +checkout_ui_extension(purchase.checkout.block.render) -
First observed: 2026-05-27
Impact
This silently breaks draft orders. Any Shopify Plus merchant using cart-transforms in draft-order checkouts whose ExpandOperation output for an expanded line can change in-session is affected. There’s no generic client-side workaround — any in-session re-evaluation that differs from the bake corrupts the order.
Asks
Any of the following would help us patch on our side or know to wait for a fix:
-
Confirmation of whether this is a known regression tied to the recent draft-order change (the same one that started rendering expansion children in the draft-order admin today).
-
Any notes on what changed in draft-order cart-transform handling, so we can understand the new contract.
-
Guidance on the intended behavior when a cart-transform re-emits a different
ExpandOperationon a draft-order checkout, and whether there’s a recommended pattern to avoid the corruption in the meantime.
Happy to provide more information on request. Thank you.
thanks for the detailed write-up and the repro steps! That made it quick to track down.