Deployment fails with ENOENT, despite file being present

Support
, ,
1

Summary
When running Parcel during a deployment, it fails with

🚨  /opt/build/repo/website/resources/denys-nevozhai-3i5kX5LVDV0_450.jpg: ENOENT: no such file or directory, open '/opt/build/repo/website/resources/denys-nevozhai-3i5kX5LVDV0_450.jpg'

This file is present both in Netlify and on Git.

Debug attempts
I’ve verified that the files exist in Netlify by prepending echo $PWD && ls -l && ls -l resources to the build command. This outputs

7:14:56 AM: > echo $PWD && ls -l && ls -l resources && parcel build ./index.html
7:14:56 AM: /opt/build/repo/website
7:14:56 AM: total 272
7:14:56 AM: drwxr-xr-x   2 buildbot root      4096 Nov 28 06:14 css
7:14:56 AM: -rw-r--r--   1 buildbot root      2737 Nov 28 06:14 index.html
7:14:56 AM: drwxr-xr-x   2 buildbot root      4096 Nov 28 06:14 js
7:14:56 AM: drwxr-xr-x 545 buildbot nogroup  20480 Nov 28 06:14 node_modules
7:14:56 AM: -rw-r--r--   1 buildbot root       348 Nov 28 06:14 package.json
7:14:56 AM: drwxr-xr-x   3 buildbot root      4096 Nov 28 06:14 parcel
7:14:56 AM: drwxr-xr-x   2 buildbot root      4096 Nov 28 06:14 resources
7:14:56 AM: -rw-r--r--   1 buildbot root    231367 Nov 28 06:14 yarn.lock
7:14:56 AM: total 32248
7:14:56 AM: -rw-r--r-- 1 buildbot root  1675540 Nov 28 06:14 asgeir-pall-juliusson--90kxRqKSmc.jpg
7:14:56 AM: -rw-r--r-- 1 buildbot root  1468361 Nov 28 06:14 denys-nevozhai-3i5kX5lVDV0_1920.jpg
7:14:56 AM: -rw-r--r-- 1 buildbot root    87544 Nov 28 06:14 denys-nevozhai-3i5kX5lVDV0_450.jpg
7:14:56 AM: -rw-r--r-- 1 buildbot root   337864 Nov 28 06:14 denys-nevozhai-3i5kX5lVDV0_900.jpg
7:14:56 AM: -rw-r--r-- 1 buildbot root  3433946 Nov 28 06:14 denys-nevozhai-3i5kX5lVDV0.jpg
7:14:56 AM: -rw-r--r-- 1 buildbot root   524533 Nov 28 06:14 glebson-kozenko-1v-snxcyHHk_900.jpg
7:14:56 AM: -rw-r--r-- 1 buildbot root 11879247 Nov 28 06:14 glebson-kozenko-1v-snxcyHHk.jpg
7:14:56 AM: -rw-r--r-- 1 buildbot root   113289 Nov 28 06:14 jason-leung-oCyVkyV3nBw_450.jpg
7:14:56 AM: -rw-r--r-- 1 buildbot root   376669 Nov 28 06:14 jason-leung-oCyVkyV3nBw_900.jpg
7:14:56 AM: -rw-r--r-- 1 buildbot root  5040031 Nov 28 06:14 jason-leung-oCyVkyV3nBw.jpg
7:14:56 AM: -rw-r--r-- 1 buildbot root   177205 Nov 28 06:14 pascal-meier-tXpD84c8ZwI_450.jpg
7:14:56 AM: -rw-r--r-- 1 buildbot root   642599 Nov 28 06:14 pascal-meier-tXpD84c8ZwI_900.jpg
7:14:56 AM: -rw-r--r-- 1 buildbot root  7233739 Nov 28 06:14 pascal-meier-tXpD84c8ZwI.jpg

As you can see, the file exists and is in the correct directory.

I am suspecting that this is a Parcel issue, since the other support thread with this problem also uses Parcel, and the file seems to exist in the the deployment VM. Regardless, I posted here for Netlify-specific input.

Netlify ID
frosty-neumann-29ea7c

2

After some debugging I have found out:

  • The error is thrown by an fs.createReadStream(...) inside Parcel (specifically in utils/md5.file). It seems like the actual open syscall errors.

  • The error does not occur if you use fs.readFileSync(...) before Parcel is run. It does occur if you do so after. The file is however visible using fs.readdirSync(...) no matter what, even when fs.readFileSync(...) will fail.

  • The error somehow got fixed after I messed around with the filename. It works after I change it to test_450.jpg, then also worked when I revert it back. That… seems really weird. I’m not sure how any state is able to persist across different deployments to affect this.

In conclusion this seems like a really weird interaction between Netlify and Parcel, which causes the open syscall to fail after Parcel has run in some cases.

Relevant build logs on Netlify:

3

Also going to just link the issue I opened on Parcels’ GitHub, in case any additional information appears there. However, considering that this seems like the actual open syscall fails, I think this is mostly in Netlify’s court.

4

Hi, @birjolaxew, welcome to our Netlify community site and … wow. This is an amazingly well researched and documented issue.

I also didn’t see any explanation for this as I also see the file present and named correctly. Case-sensitivity issues are known to cause issues like this but the case matches exactly.

I’m asking my colleagues to take a look as well and we hope to have more information for you soon.

6

to Luke’s point @birjolaxew, I am also still worried about case sensitivity and the “test_450” file working makes me think that may be related, still. However, while investigating, I saw this line in your error output from one of your last failed builds:

/opt/build/repo/website/resources/denys--3i5kX5LVDV0_450.jpg

…which has 2 dashes in it after denys. I guess that isn’t the case in what you pasted…but it is what I see in the deploy logs, similar to Asgeir’s entry in your paste here: (asgeir-pall-juliusson--90...)

7

@fool That file name is from when I was attempting to debug by removing parts of the filename. After I saw that it worked after renaming to test.jpg, I was wondering if somehow a specific part of the filename was triggering the bug. In a previous build I had also tried simply 3i5kX5LVDV0_450.jpg. Eventually I reverted back to the original filenames, which somehow worked. That’s the most confusing part to me. Both of those builds are of the debug branch, so they might be a bit messy. The relevant commits on master are 5923f2 (fails), 70c1b1 (succeeds) and b1d32a (succeeds).

As for Asgeir’s entry, that’s simply because the photo’s Unsplash ID starts with a dash :wink:

8

Eventually found out that you guys were right - the L in 3i5kX5LVDV0 was uppercase in my require, but lowercase in my filename. Guess I must’ve updated it when I named the file back to its “original” filename. I’ll have to take a look at how the Git ended up differing from my local system, but this definitely isn’t a Netlify issue.

Thanks for having a look anyway you two!