Yarn cache has problems for ~10% of deploys

[RossWilliams]

** Please describe which feature you have a question about? ** I seem to run into deployment problems with yarn's cache, only when doing console deploys, and usually for a different package each time. The last few are below.

I don't have caching turned on in build settings, or any other exotic configuration, just running yarn install in the build step causes these issues. Is there a setting I can enable so this doesn't occur?

Also, the build email notifications are not helpful, I don't need my inbox filled with emails for each build, I only need emails in case of failure

It wouldn't be so frustrating if the whole deploy cycle didn't take 20 minutes, and these failures are in the frontend build, 16 minutes into the process, even when there are no backend changes.

** Provide additional details** error An unexpected error occurred: "ENOENT: no such file or directory, open '/usr/local/share/.cache/yarn/v4/npm-retry-0.12.0-1b42a6266a21f07421d1b0b54b7dc167b01c013b/node_modules/retry/.yarn-metadata.json'". 2020-01-23T12:34:33.167Z [INFO]: info If you think this is a bug, please open a bug report with the information provided in "/codebuild/output/src052057409/src/s12/src/yarn-error.log"

2020-01-22T16:18:07.662Z [WARNING]: error https://registry.yarnpkg.com/json-buffer/-/json-buffer-3.0.0.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, stat '/usr/local/share/.cache/yarn/v4/npm-json-buffer-3.0.0-5b1f397afc75d677bde8bcfc0e47e1f9a3d9a898/node_modules/json-buffer/LICENSE'"

2020-01-22T14:01:37.278Z [WARNING]: error https://registry.yarnpkg.com/@babel/runtime/-/runtime-7.3.1.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, chmod '/usr/local/share/.cache/yarn/v4/npm-@babel-runtime-7.3.1-574b03e8e8a9898eaf4a872a92ea20b7846f6f2a/node_modules/@babel/runtime/helpers/esm/newArrowCheck.js'"

2020-01-20T14:38:37.282Z [WARNING]: error https://registry.yarnpkg.com/@babel/runtime/-/runtime-7.3.1.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, chmod '/usr/local/share/.cache/yarn/v4/npm-@babel-runtime-7.3.1-574b03e8e8a9898eaf4a872a92ea20b7846f6f2a/node_modules/@babel/runtime/helpers/esm/toPropertyKey.js'"

2020-01-23T14:41:12.800Z [WARNING]: error https://registry.yarnpkg.com/array-includes/-/array-includes-3.0.3.tgz: Extracting tar content of undefined failed, the file appears to be corrupt: "ENOENT: no such file or directory, chmod '/usr/local/share/.cache/yarn/v4/npm-array-includes-3.0.3-184b48f62d92d7452bb31b323165c7f8bd02266d/node_modules/array-includes/.travis.yml'"

[indiejoseph]

after a year, Still struggling with this problem, 20% of the build failed due to yarn install cache failed

[hubsmoke]

I saw this problem crop up last year and it remains unfixed. I've been a user of Amplify since its initial public release and previously was satisfied with the experience of consistent build success. Nowadays, I never know if a build failure is due to an IO error on the build container (ENOENT). In practice I deal with this issue by retrying the build manually and it usually succeeds after one retry. However, this is not sustainable at scale and leaves the dev team with lack of confidence in the Amplify product. I want to enforce build success as a criteria for Pull Request acceptance, but I can't due to these sporadic build failures. I'm contemplating creating a script or web service to automate retrying the build. Perhaps outside of fixing the core issue a workaround would be to allow a number of retries per build with a max. I would set my max retry to 1 or 2. Ideally the core problem is fixed by ensuring the network reliability for these build process containers.

If this problem isn't addressed I will be convinced to explore options outside of Amazon Amplify.

Further detail: I've noticed these problems on my core dev stack using Node.js+Yarn. Generally these errors seem to be due to failure to download a dependency from the yarn registry. It is therefore unclear whether the problem is on the yarn registry or Amplify, however in practice I have never experienced issues with the Yarn registry outside of AWS Amplify, leading me to believe it is highly likely that there is a networking issue for these build process containers.