Inconsistent lastName enforcement on Order/DraftOrder shippingAddress

GraphQL Admin API Troubleshooting
1

Problem

The MailingAddressInput documentation marks no name fields as required. In practice, however, the Admin GraphQL API enforces lastName on shippingAddress inconsistently across the Order and DraftOrder mutations — sometimes silently dropping the address, sometimes erroring, sometimes accepting it. The behaviour is non-deterministic from the caller’s perspective and not reflected in the schema or docs.

We believe this is a bug — or at minimum a documentation gap that needs to be closed. A prior community thread reports the same symptom: shippingAddress and billingAddress are not saving to order via orderCreate.

Reproduction

In all four cases below, the shippingAddress input is identical except that lastName is omitted (or empty). According to the schema, this should be valid.

1. orderCreate No userErrors are returned. The order is created, but the shippingAddress is silently dropped with no indication to the caller.

2. orderUpdate Returns a userError complaining that lastName is required.

3. draftOrderCreate Accepted without error. The draft order persists a shippingAddress with an empty lastName.

4. draftOrderComplete (promote draft → order) The draft’s shippingAddress (with missing lastName) is carried over to the resulting order — it is not dropped as in case 1. However, any subsequent orderUpdate on that order then fails with the same lastName error as case 2, even if the update does not touch the address.

Expected behaviour

One of the following, applied consistently across all four mutations:

  1. lastName is genuinely optional — accept the address as written, and update the docs/schema accordingly. (Preferred.)

  2. lastName is required — mark it as non-null in MailingAddressInput, and return a userError (never silently drop) on every mutation that takes a shipping address.

The current state — silent drops on orderCreate, userErrors on orderUpdate, persisted-but-broken state on draft orders — is the worst of all worlds: callers cannot detect the failure at write time, and the resulting order is then permanently unupdatable without first patching the address.

Ask

Could the API team please confirm whether lastName is intended to be required, and either (a) enforce it consistently with a userError on all mutations, or (b) remove the enforcement entirely? Either resolution would be acceptable; the silent-drop variant is what makes this currently a production hazard.

Happy to provide concrete request/response payloads if helpful.

2

Hi @Merlijnmac - thanks for the detailed write-up, this is a really clear breakdown and you’re right that the behaviour is inconsistent. I reproduced all four cases on a test store and saw exactly what you described, including the silent drop on orderCreate where the address is discarded with no userError. You’re also correct that MailingAddressInput marks lastName as optional, so the runtime enforcement isn’t visible from the schema.

In my testing an order created from a completed draft with a blank lastName isn’t permanently unupdatable, since an orderUpdate that doesn’t touch the address (for example updating a note or email) succeeds fine. Only an orderUpdate that includes a shippingAddress re-runs the validation and fails on the blank last name. In the meantime, the reliable workaround is to always send a non-empty lastName in shippingAddress, since sending it empty behaves the same as omitting it.

I’ve raised the inconsistency with both the orders and draft orders teams to confirm the intended behaviour and whether the schema/docs should be clarified. I’ll post back here once I hear from them - thanks for raising this here!

4

@Donal-Shopify Thank you for the quick response! Excited to hear how it gets resolved :slight_smile: