Order editing API: "Another staff member may be editing this order"

Our app edits orders by calling orderEditBegin, then sends several orderEditSetQuantity and orderEditAddVariant mutations concurrently against the same CalculatedOrder, then orderEditCommit (Admin GraphQL 2025-01).

Since roughly 2026-09-23 to 09-27, when an edit has more than about 30 changes, some of them return HTTP 200 with:

userErrors: [{ field: ["id"], message: "Another staff member may be editing this order. Try again." }]

No one else is editing the order. The rejections all arrive together, about 10 seconds after the requests were sent, and the requests that complete do so one at a time, about 0.35–0.4s apart. It looks like mutations on a calculated order are serialized, and a request still waiting after about 10s is rejected.

Questions:

  1. Was a change made to how concurrent order-edit mutations are handled (a lock or wait timeout) in late September 2026?
  2. Is the ~10s wait limit documented, and is it a fixed value?
  3. Is sending the changes as aliased mutations in a single request, one request at a time, the recommended pattern? That works for us with no rejections.

Hi @derrick, I’m reviewing changes made around that time to determine whether they relate to the behavior you’re seeing. I’ll get back to you with my findings.
What I can confirm now is that edits to the same CalculatedOrder are processed one at a time, so concurrent requests can be rejected with this user error.

To answer your other questions:

  1. The observed wait duration is not a documented API guarantee and shouldn’t be treated as fixed.

  2. The recommended pattern is to keep one request in flight per CalculatedOrder. Aliased top-level mutations in a single request are one way to do this because GraphQL executes them serially. Use modest batches, send one batch at a time, and retry this user error with backoff. When you’re satisfied with the staged changes, use orderEditCommit to finalize them.

Thanks @Paige-Shopify.