Summary
fileDelete consistently fails when the files in one mutation carry a large total number of references: the call hangs for ~143 seconds and then returns a transport-level HTTP 500 with a plain-text Internal Server Error body (not a GraphQL JSON error response). We first saw this in production on a merchant’s shop, and we have now reproduced it on a clean development store with a minimal recipe (below), including a request ID.
API version: 2026-04
The request
mutation fileDelete($fileIds: [ID!]!) {
fileDelete(fileIds: $fileIds) {
deletedFileIds
}
}
Reproduction (clean development store)
- Create 60 products, each with 100 variants.
- Upload 60 small PNG files (staged upload +
fileCreate), wait for READY. - Attach file i to ALL 60 products (
fileUpdatereferencesToAdd) and append it to product i’s 100 variants (productVariantAppendMedia) → each file ends up with ~160 references, ~9,600 references across the batch. - Call
fileDeletewith all 60 file ids in ONE mutation.
Result: request hangs 143.78s → HTTP 500, body Internal Server Error (plain text).
X-Request-ID: 2fa18c62-5d2f-4f30-9be7-ab23823be3c9-1781158853 (2026-06-11, development store)
The failure threshold is dose-dependent — same store, same mutation, increasing total references:
| Total references in one fileDelete | Composition | Result |
|---|---|---|
| ~121 (1 file) | mostly variant refs | OK in 3.84s |
| ~300 (50 files) | mixed | OK in 9.56s |
| ~5,850 (45 files) | product refs only | OK in 41.13s |
| ~9,600 (60 files) | variant-heavy | 143.78s → HTTP 500 |
Two observations from the data: the per-reference cost is roughly linear (and variant references appear ~4-5x more expensive to unwind than product references), and the ~143s cutoff looks like a fixed server-side execution budget — production failures on the merchant’s shop died at 142.4–142.9s, identical to the repro.
Production occurrence
Merchant shop (domain available via DM), products with large variant matrices where each image is attached to many variants. Deleting one product’s media (chunks of up to 200 file ids) fails every time with the same signature. Failing calls observed 2026-06-10 at 06:20:32→06:22:55, 06:25:23→06:27:46, 06:30:14→06:32:36 UTC. Everything else on the shop works (queries, staged uploads, fileCreate, fileUpdate, productVariantAppendMedia) — only fileDelete fails.
This also matches the earlier unresolved report in fileDelete mutation limitations (files with 100+ references failing with “Internal error”, including a 490-reference file that could not be deleted through the Admin UI either).
Workaround we verified
Detaching the references first (fileUpdate with referencesToRemove) and then deleting files individually succeeds reliably — our repro’s cleanup deleted the exact same 60 files that the bulk call could not.
Questions
- Is there a documented (or documentable) limit on total reference-unwind work per
fileDeletecall? - Is the ~143s hang + non-GraphQL plain-text 500 the intended failure mode? A fast GraphQL
userErrorwould let clients degrade gracefully instead of burning 2+ minutes per attempt. - What is the recommended pattern for deleting reference-heavy files — smaller batches, detach-then-delete, or something else?
thanks for flagging and for the detailed writeup, that’s very helpful.