Potential Order Edit API Bug? Commit Returns Error But Still Applies Changes

GraphQL Admin API Troubleshooting
1

In the Order Edit API the orderEditCommit returns an error while still silently applying the edits. This causes apps with standard retry logic to create duplicate line items. When committing order edits, Shopify intermittently:

  • Returns an error response
  • Still applies the edits in the background
  • Does NOT log the edit in the order timeline

This is the error:

{
“errors”: “Internal Server Error”,
“error_reference”: “If you report this error, please include this id: 9095696d-49b0-4c83-8d8b-5bf63da15808-1772644700.”
}

The app has rollback protection, so when we see this error, we assume the commit failed and retry. However, Shopify is raising the error and still applying the edits, this inflated line item quantities.

Timeframe

  • First Observed: Feb 18, 2026, 9:30 PM UTC
  • Most recent: March 11, 2026 at 10:38 PM UTC

Has anyone else experienced similar behavior with the Order Edit API?

2 Likes
2

Hey @George_M, thanks for sharing that. Based on your explanation it sounds like the commit job is completing, but something is causing an error instead of the expected response.

I can look in to this. How often are you seeing this and have you identified any way to replicate it? (ie does it happen with certain types of order edits and not on other types).

In the meantime I would also recommend to query the order before re-trying to better verify if the commit was successful or not.

4

Thanks @KyleG-Shopify for taking a look at this. The behavior appears random with no clear reproducible pattern so far. In the cases we’ve observed, it has only affected orders created through the Online Store channel. We have not yet seen it occur on Draft Orders. We’ve now observed this across two different merchant stores:

  • In one store, the duplication is relatively small (for example bundle component line items appearing twice).

  • In another store, the duplication escalates significantly, producing hundreds or even thousands of duplicate line items.

Both seem consistent with a scenario where orderEditCommit returns an error but the edit operation still completes on Shopify’s side, which then causes retry logic on the app side to apply the changes again. We currently have an open support ticket with Shopify (Ticket #64770631) where we shared specific order examples.

Thanks for the suggestion about querying the order before retrying the commit. I’ll check in with the team on this from our side.

Let me know if you need further information.

Edit: Another similar case was just reported but this time from a Draft order (March 11, 2026 at 11:29 AM UTC)

5

Hi Kyle,

Thanks again for looking into this, really appreciate it. I had a chance to speak with our dev team about the suggestion to query the order before retrying, and I wanted to share a bit more context on why this is difficult for us:

  • We process a high volume of order edits, so adding verification queries for each one introduces significant overhead.
  • When adding line items, Shopify doesn’t return identifiers we can reliably match back to our original requests.
  • For larger orders where the same items are added in batches, it becomes difficult to determine which line item came from which commit.
  • If there’s an actual failure (API downtime, order locked by another process, etc.) and we query the order looking for our edits, we could get false positives — matching against items that were added by something else entirely.
  • Race conditions are also a concern. If the order is being modified concurrently, our verification check could pick up edits from another source and assume ours succeeded.
  • This could also lead to data mismatches on our side if we incorrectly associate line items with the wrong edit request.

Our system relies on the orderEditCommit response to confirm what was applied. A successful response means we record it, while an error triggers a retry. When an error is returned but the edit still goes through, it breaks that flow and can lead to duplicates.

We can explore possible workarounds on our side, but receiving a reliable response from the API would be the cleanest solution. Is this something that might already be tracked as a bug?

Thanks again for your help.

1 Like
6

Closing the loop on this thread, the issue reported here should now be solved. If anyone does notice similar behaviour though, let is know. Thanks for reporting this George!

1 Like