Network mutex may enter infinite recursion if port is in use by non-Yarn

[robhogan]

Yarn classic is unmaintained - I'm just noting this here as a point of reference/pointer for others

When using --mutex=network, Yarn attempts to start an HTTP server on the configured port. If it fails, it tries to ask whatever is listening for its name, and then waits for it if it appears to be a Yarn process.

This can go wrong in a few ways, often leading to infinite recursion due to the retry behaviour.

• If Yarn isn't allowed to listen on the configured port.
• The listening process doesn't respond to an HTTP request (hangs or closes).
• The listening process is a non-Yarn HTTP server that responds with JSON (Yarn tries to wait for it by opening a socket)

yarn/src/cli/index.js

Lines 419 to 447 in 158d96d

	function reportServerName() {
	const request = http.get(connectionOptions, response => {
	const buffers = [];
	response.on('data', buffer => {
	buffers.push(buffer);
	});
	response.on('end', () => {
	try {
	const {cwd, pid} = JSON.parse(Buffer.concat(buffers).toString());
	reporter.warn(reporter.lang('waitingNamedInstance', pid, cwd));
	} catch (error) {
	reporter.verbose(error);
	reject(new Error(reporter.lang('mutexPortBusy', connectionOptions.port)));
	return;
	}
	waitForTheNetwork();
	});
	response.on('error', () => {
	startServer();
	});
	});
	request.on('error', () => {
	startServer();
	});
	}

The only circumstance where Yarn correctly reports Cannot use the network mutex on port 31997. It is probably used by another app is when the listening process is an HTTP server that responds with anything other than JSON.

We're patching this locally by not retrying with startServer() on errors, and adding a timeout for unresponsive sockets.