Bug: orderUpdate rejects valid metafield writes when the order carries an unrelated metafield that fails its definition's validation

GraphQL Admin API Troubleshooting
1

Hi folks, we’ve hit what looks like a validation bug in the Admin GraphQL API orderUpdate mutation.

Setup: an order carries a metafield Z (single_line_text_field with choices validation) whose stored value is no longer in the definition’s choices list (the definition was edited after the order was created).

Action: call orderUpdate writing only a single unrelated metafield X in a different namespace:

mutation($id: ID!, $metafields: [MetafieldInput!]) {
  orderUpdate(input: { id: $id, metafields: $metafields }) {
    userErrors { field message }
  }
}

with metafields containing exactly one valid entry.

Actual: the whole update is rejected with a userError about metafield Z, e.g. field: ["metafields", "4", "value"], message: "Value does not exist in provided choices: [...]". Note the index: we sent one metafield, so index 4 can only refer to the order’s pre-existing metafields collection - the mutation appears to re-validate all metafields on the order, not just the ones in the input.

Expected: metafield X is written; metafield Z is untouched and not validated, since the input doesn’t reference it.

Impact: for apps, any order that carries a stale metafield value (from a definition edited after the fact, by any app or the merchant) becomes permanently un-updatable via orderUpdate, and there’s nothing the app can do about a metafield it doesn’t own.

Shopify request ID: 0284e35e-27c8-44cb-b9a8-126ba663fb23-1788168523

3

Hi @Patrick_Jakubik! I pulled the logs for the request ID you shared and the trace confirms that the orderUpdate request contained a single metafield, but returned a choices-validation error at index 4. That points to another stored order metafield rather than the value you submitted.

I’ve raised this with the relevant team for review. In the meantime, metafieldsSet is a working workaround for this choices-validation scenario. I tested it on an Order that retained an unrelated stale choices value, and it wrote the requested metafield while leaving the stale value unchanged.

For metafield-only writes on affected orders, use metafieldsSet with the Order ID as ownerId instead of including the metafield in orderUpdate.

Thanks for flagging this here!