[Bug]: receiving a return crashes with duplicate order_shipping_method_adjustment version when the order has a shipping-method (promotion) adjustment

[d3v07]

Bug report

Receiving return items on an order that carries a shipping-method adjustment (e.g. a shipping promotion) throws a unique-constraint violation instead of completing:

Order shipping method adjustment with version: 3, shipping_method_id: ordsm_..., already exists.

Reproduction

Reproduced via createAndCompleteReturnOrderWorkflow with receive_now: true, against an order whose shipping method has an adjustment:

await createAndCompleteReturnOrderWorkflow(container).run({
  input: {
    order_id: order.id, // order has a shipping_method with an adjustment
    return_shipping: { option_id: shippingOption.id },
    items: [{ id: order.items[0].id, quantity: 1, reason_id: reason.id }],
    receive_now: true,
  },
  throwOnError: true,
})

100% reproducible locally against Postgres 15 (identical failure every run — not a flake).

Precise trigger (empirically isolated)

Only orders with a shipping-method adjustment fail:

• Order with a shipping-method adjustment + receive_now: true → crashes
• Same order without the shipping-method adjustment → passes
• Item-level adjustments do not trigger it (only shipping-method adjustments do)

The collision happens on the RETURN_RECEIVE order-change, which bumps the order version and re-creates order_shipping_method_adjustment rows. It attempts to insert a row for a (version, shipping_method_id) pair that already exists, violating IDX_order_shipping_method_adjustment_version_shipping_method. This looks related to the shipping-method-adjustment/versioning family of issues (#14819, #14484, #15919), but manifests as a hard crash on receive rather than an incorrect total.

Stack (abridged)

at dbErrorMapper (packages/core/utils/src/dal/mikro-orm/db-error-mapper.ts:35)
at AbstractService_.update (packages/core/utils/src/modules-sdk/medusa-internal-service.ts:340)
at OrderModuleService.receiveReturn (packages/modules/order/src/services/actions/receive-return.ts:108)
at OrderModuleService.receiveReturn_ (packages/modules/order/src/services/order-module-service.ts:4241)
... applyOrderChanges_ -> orderShippingMethodAdjustmentService_.create

Ruled out

• Not a flake — 3/3 identical local repros against Postgres 15.
• Not the promiseAll in receive-return.ts — serializing updateReturns / updateReturnItems into sequential awaits does not fix it; the failure originates earlier, in confirmOrderChange → applyOrderChanges_.
• Not caused by any in-flight change — reproduces identically on unmodified develop.

Environment

• Reproduced against a local Postgres 15 container, Node 25, yarn 3.2.1, on develop.
• Discovered via fix(core-flows): only emit RETURN_RECEIVED when receive_now is true #15856.

[medusa-os-bot]

Thanks for reporting this! We've labeled it as a bug and will investigate.

Confirmed bug in the order module. Receiving a return (createAndCompleteReturnOrderWorkflow with receive_now: true) on an order whose shipping method carries an adjustment (e.g. a shipping promotion) throws a unique-constraint violation on IDX_order_shipping_method_adjustment_version_shipping_method. The RETURN_RECEIVE order-change bumps the order version and re-creates order_shipping_method_adjustment rows via applyOrderChanges_, attempting to insert a (version, shipping_method_id) pair that already exists. Only shipping-method adjustments trigger it; item-level adjustments do not. Reporter says it is 100% reproducible on unmodified develop against Postgres 15. The referenced files and the unique index exist in the codebase as described. A fix appears to be in progress in open PR #16029 (don't recreate past-version shipping method adjustments on order change); merged PR #15856 addresses a different (event-emission) aspect. Related to the shipping-method-adjustment/versioning issues…