nrwl/nx

Project graph is not generated on systems with slow socket connection times due to 5 sec timeout

Opened this issue · 2 comments

zfor commented

Current Behavior

If the plugin worker is not able to start in 5 seconds, any Nx command that requires the project graph will fail.

Expected Behavior

For the unfortunate developers who are blessed with multiple different security policies and scans that artificially slows down the time it takes to create and connect to a socket, the timeout should at least be configurable.

The change was introduced by the following lines in this commit:
1bf0e67#diff-38ac9b63319495de2d963b7982a2db8741f5dcfb790e5816384152236389fcb3R150-R157

Due to these security scans in our case, these plugins – that would normally take a few hundred milliseconds to load in the real world –, takes around 12000 (!!!) milliseconds to load based on the daemon.log (which I was able to get by increasing the 5 sec timeout in the source itself).

Would it be possible to make this configurable through nx.json or env variables?

GitHub Repo

N/A

Steps to Reproduce

  1. Get a system where a myriad of security scans artificially slow down the system to the point where connecting to a local socket takes more than 5 seconds.
  2. Try and run any Nx command that requires the project graph

Nx Report

Node           : 22.11.0
OS             : win32-x64
Native Target  : x86_64-windows
npm            : 10.9.0

nx                     : 20.2.2
@nx/js.                : 20.2.2
@nx/jest               : 20.2.2
@nx/eslint             : 20.2.2
@nx/workspace          : 20.2.2
@nx/angular            : 20.2.2
@nx/cypress            : 20.2.2
@nx/devkit             : 20.2.2
@nx/eslint-plugin      : 20.2.2
@nx/module-federation  : 20.2.2
@nx/node               : 20.2.2
@nx/plugin             : 20.2.2
@nx/web                : 20.2.2
@nx/webpack            : 20.2.2
typescript             : 5.4.5

Failure Logs

In Nx daemon logs:

The plugin worker is exiting as it was not connected to within 5 seconds.

Package Manager Version

No response

Operating System

  • macOS
  • Linux
  • Windows
  • Other (Please specify)

Additional Information

I understand that this is an edge case and 5 sec would fit 99.9% of the user base, but introducing arbitrary timeouts always have this kind of risks and we should be able to override them through config.

vaopaat commented

ah, we're facing the same issue. Any help would be welcome.

  • 👍1
l-Leniac-l commented

having the same issue on Azure Pipelines and some of my coworkers' computers

  • 👍1