creates and upload the file if it doesn’t exist in Shopify
if it exists, and it is an image we update via fileUpdate the alt and filename if those are changed on our end.
For some reason, we get FILE_LOCKED. We went into Shopify Admin, tried to update the alt there, and it failed with the same reason.
What is locking the file? How can I see that piece of information to understand what’s going on?
ALSO, AN IMPORTANT THING TO NOTE: by the time we update, the fileCreate part works successfuly, and returns status READY. So, something is going on in the period between fileCreate and fileUpdate. And that can be hours.
If you’re able to, could you share the full error response you’re seeing on your end (including the X-Request-ID from the API response header if possible)?
I can take a look at our logs and see if we can find out what’s triggering this, since it is definitely odd that the error pops up in the admin too.
Thanks @Stefan_Buciu - appreciate you sending that my way. I was able to pull some logs and verified that it does look like a file lock issue in the database on our end. I can’t say for sure why that’s happening, but I’ve reached out to our developers to investigate further - I’ll be in touch again as soon as I have more info for you here
Hey again @Stefan_Buciu - I was able to touch base with our developers on this for you. We were able to narrow down the problematic file, but noticed that it seems to have been deleted/removed from the shop from what we can tell.
Would you be able to share the last part of the admin link (just omitting the myshopify.com name of the shop) and share the link to the file if it’s still uploading or if the issue is still persisting (for example if you created a new file?). It should look like this:
If you did create a new image file and are still seeing the link, we can still help for sure, but if you can keep that new file “undeleted” we can take a look at its status and figure out what’s triggering the locks.
Hi @Alan_G, thanks for the quick responses. We had to delete the media and re-sync since it was a blocker. But the next time I encounter this, I will write here. Now I tried to make some updates and it worked.
I am confident that it will happen again, since it occurred twice in 3 days already (for many files). But it may take a couple of hours, I will update tomorrow.
Thanks @Stefan_Buciu - I was able to touch base with our devs on this for you too and they noticed that file ID 36545858437339 is no longer locked.
They’re just wondering if you’re automatically deleting those files when they get stuck (no worries if so - just wanted to confirm behaviour on your end).
If possible, could you keep a file in that “locked” state without removing/deleting it the next time you catch this happening and share the request id/file id? We can take a look at that while it’s in the locked state to see if we can track the error.
Hey @Stefan_Buciu - sorry for the back and forth on this one here a bit - our devs took another look and it seems like that example file may have been deleted/removed as well.
They have set aside some time to look into this though (can’t guarantee exact times, but they mentioned they will look into this further on Monday EST).
Would you be able to share the full steps your app is using to create/update the file when you see this get triggered (including the exact mutations and variable input being used, etc)? We just want to see if we can trigger the same behaviour on our end to narrow down the root cause since it does seem odd that this is happening regularly for you for sure.
- FILE_LOCKED usually means there’s a pending operation waiting for processing on a particular file: 
