Lerna bootstrap fails due to concurrency (with npm)

The latest RC version fails when running lerna bootstrap. I’m not sure when it was introduced, though, because only today builds started failing on Travis while RC3 was released 8 days ago. So, I may be actually running into two separate issues. Both turned to have the same solution, though, switching off concurrency.

The issue, at least now, can be reproduced in the following way:

p@m /workspace/test> git clone [e-mail]:ckeditor/ckeditor5.git
Cloning into 'ckeditor5'...
remote: Counting objects: 6484, done.
remote: Compressing objects: 100% (71/71), done.
remote: Total 6484 (delta 32), reused 0 (delta 0), pack-reused 6407
Receiving objects: 100% (6484/6484), 1.16 MiB | 336.00 KiB/s, done.
Resolving deltas: 100% (3672/3672), done.
p@m /workspace/test> cd ckeditor5/
(master cbe80fd) p@m /workspace/test/ckeditor5> lerna bootstrap
Lerna v2.0.0-rc.3
Bootstrapping 1 packages
Preinstalling packages
Installing external dependencies
Installing hoisted dependencies into root
Pruning hoisted dependencies
FileSystemUtilities.rename    ("./package.json", "./package.json.lerna_backup")
Error: ENOENT: no such file or directory, rename '/workspace/test/ckeditor5/package.json' -> '/workspace/test/ckeditor5/package.json.lerna_backup'
    at Error (native)
NpmUtilities.installInDir     (".", ["guppy-pre-commit@^0.4.0"], {})
Error: ENOENT: no such file or directory, rename '/workspace/test/ckeditor5/package.json' -> '/workspace/test/ckeditor5/package.json.lerna_backup'
    at Error (native)
Errored while running BootstrapCommand.execute
Error: ENOENT: no such file or directory, rename '/workspace/test/ckeditor5/package.json' -> '/workspace/test/ckeditor5/package.json.lerna_backup'
    at Error (native)

When I try with --concurrency=1 the issue doesn’t seem to appear:

(master cbe80fd) p@m /workspace/test/ckeditor5> lerna bootstrap --concurrency=1
Lerna v2.0.0-rc.3
Bootstrapping 1 packages
Preinstalling packages
Installing external dependencies
Installing hoisted dependencies into root
Pruning hoisted dependencies
Symlinking packages and binaries
Postinstalling packages
Prepublishing packages
Successfully bootstrapped 1 packages.

It also proved to help with a bit more complicated situation I had on Travis: https://travis-ci.org/ckeditor/ckeditor5/builds/226105896. It worked well after disabling concurrency: https://travis-ci.org/ckeditor/ckeditor5/builds/226101027.

I can see that similar issues were already reported: https://github.com/lerna/lerna/issues/397 and https://github.com/lerna/lerna/issues/616. However, this may be the first scenario in which the issue can be easily reproduced.

Your Environment

Executable	Version
lerna --version	2.0.0-rc.3
npm --version	4.0.3
node --version	6.9.1

OS	Version
macOS Sierra	10.12.4

[Reinmar]

Unfortunately, I didn’t save it as I went straight to npm-debug.log (which is usually more helpful so Lerna could mention that to the user). In the console, as I recall, there was just an info about crashing processes.

I know that the npm log indicates that some JSON was missing/invalid, but I’ve seen the same error many times in the past. Usually, a second lerna bootstrap run would help with that. So, my assumption now, when I discovered that lerna bootstrap --concurrency=1 helps even more consistently is that:

• one Lerna process starts installing package X,
• a second process tries to install the same package at the same time,
• there’s some mutex failure and the second process thinks that the package is already available in npm’s cache (/Users/me/.npm) but it isn’t or is temporarily invalid at that moment,
• the second process crashes while trying to read this file.

And why does it work when running lerna bootstrap for the second time (even concurrently)? Because the cache is already hot and all JSONs are usually already unpacked there.

Anyhow reasonable?

[Brantron]

We finally have a reliable workaround!!!

install: travis_retry make ci-install

where the makefile does

ci-install:
	yarn;
	lerna bootstrap --mutex file:/tmp/.yarn-mutex --concurrency=1;

The key is travis_retry where it will attempt the installation 3 times. So far we have 100% success.