module-federation-dev-server can hang indefinitely due to child process running build can exit before success message is printed

[jooskim]

Current Behavior

We have a mono-repo setup with multiple MFE apps including a host application. The host application uses the @nx/angular:module-federation-dev-server executor to launch the dev server, which builds all configured MFE projects before kicking off the host application.

Assuming the host application's project name is host, we would start the local server using the standard NX command syntax of:

nx run host:serve

This would generate output logs like this:

NX Starting module federation dev-server for <redacted> with 8 remotes
NX Building 8 static remotes...

Most of the time, the build completes as indicated by the message "NX Built 8 static remotes" and the server starts. However, we noticed that under random circumstances, especially when we force NX to skip cache via --skip-nx-cache, the build never completes and therefore the server never starts. I could reproduce the issue across my colleagues machines, although not 100% of the time. Sometimes nx run host:serve --skip-nx-cache would start the server just fine. A classic case of a race.

Fast forward to now, we identified the culprit for this hang. It has to do with how module-federation-dev-server waits for MFE project builds to finish. The server implementation forks a child process to run nx run-many -t build and waits for it to emit a certain string that indicates the build has finished successfully (i.e. Successfully ran target build). Only then does the enclosing Promise resolve, allowing next tasks to proceed until the dev server starts.

Now, when a child process exits "a little too early", its final stdout/stderr stream values could be discarded. What this entails is that the task would never complete, and this is exactly what we observed. See the following two screenshots that each represent a normal run and a run that will never resolve the Promise object.

(GOOD) A string whose presence is used to resolve the Promise is present before the child process exits

(BAD) The child process exits before it has a chance to print out its final output - Promise hangs indefinitely

Expected Behavior

Given the command nx run <host-app>:serve where uses the module-federation-dev-server executor for the serve target, the server should start successfully, with or without the --skip-nx-cache.

GitHub Repo

No response

Steps to Reproduce

1. Create one MFE host app and one remote app using @nx/angular:host and @nx/angular:remote.
2. Configure host's module-federation.config.ts to list the remote app in the remotes array.
3. Run the serve target on the host app.
4. If the server starts successfully, stop the server, repeat 3 but with --skip-nx-cache.

Nx Report

Node   : 18.20.3
OS     : darwin-arm64
npm    : 10.7.0

nx (global)        : 19.3.1
nx                 : 18.1.2
@nx/js             : 18.1.2
@nx/jest           : 18.1.2
@nx/linter         : 18.1.2
@nx/eslint         : 18.1.2
@nx/workspace      : 18.1.2
@nx/angular        : 18.1.2
@nx/cypress        : 18.1.2
@nx/devkit         : 18.1.2
@nx/eslint-plugin  : 18.1.2
@nx/express        : 18.1.2
@nx/node           : 18.1.2
@nx/playwright     : 18.1.2
@nx/plugin         : 18.1.2
@nrwl/tao          : 18.1.2
@nx/web            : 18.1.2
@nx/webpack        : 18.1.2
nx-cloud           : 18.0.0
typescript         : 5.2.2
---------------------------------------
Community plugins:
@ngneat/transloco : 4.3.0
ng-mocks          : 14.12.1
ngx-build-plus    : 14.0.0
---------------------------------------
Local workspace plugins:
<redacted>

Failure Logs

No response

Package Manager Version

No response

Operating System

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

Additional Information

I discovered the issue originally on NX 18. Tried upgrading to NX 19 to experience the same issue (because the same gap is present in child process handling). The fix I will file soon is based on the latest master which is v19.

[github-actions]

This issue has been closed for more than 30 days. If this issue is still occuring, please open a new issue with more recent context.