Error in an async lifecycle hook and router `ResolveFn` crashes Angular 16 universal server

[moonseob]

Which @angular/* package(s) are the source of the bug?

platform-server

Is this a regression?

Yes

Description

The node server built by nguniversal/express-engine crashes seems to be failing to handle errors correctly.

Reproduction

1. ng add @nguniversal/express-engine
2. Throw an error in any async function

export class AppComponent implements OnInit {
  async ngOnInit() {
    throw new Error('');
  }
  // or
  ngOnInit() {
    new Promise((_, reject) => reject(''));
  }
}

3. Build and run the universal server (i.e. npm run serve:ssr)
4. The node server crashes when it tries to run the code.

The same procedure the dependencies of Angular 15 does not crash the server.

Please provide the exception or error you saw

Node.js v18.16.0
A server error has occurred.
node exited with 1 code.

Please provide the environment you discovered this bug in (run ng version)

Angular CLI: 16.0.2
Node: 18.16.0
Package Manager: npm 9.5.1
OS: darwin arm64

Angular: 16.0.3
... animations, common, compiler, compiler-cli, core, forms
... platform-browser, platform-browser-dynamic, platform-server
... router

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1600.2
@angular-devkit/build-angular   16.0.2
@angular-devkit/core            16.0.2
@angular-devkit/schematics      16.0.2
@angular/cli                    16.0.2
@nguniversal/builders           16.0.2
@nguniversal/express-engine     16.0.2
@schematics/angular             16.0.2
rxjs                            7.8.1
typescript                      5.0.4

Anything else?

  ngOnInit() {
    throw new Error('');
    // or
    throwError(() => '').subscribe();
  }

In case of "sync" function or an observble, the server does not crash and serves the html just fine.

[moonseob]

This bug also affect router ResolveFns. Any error that is not catched inside of it will crash the server, regardless of its return type(both sync and async).

[alan-agius4]

Hi @PJms,

In both cases the problem is caused by a change in zone.js #49144 (//cc @JiaLiPassion). Which causes the rejections not to be intercepted by Zone.js and eventually passed to the ErrorHandler.

Interesting, prior this change in zone.js the error was completely ignored and not even displayed in the server console.

That being said, the lifecycle hook are not meant to be "async", and two "async" patterns highlighted above have some problems.

• async ngOnInit, this is never await and causes a floating promise as ngOnInit is sync.
• new Promise((_, reject) => reject('')); This also causes a floating promise which in general is a bad practice and does not guaranteed to be resolved prior to Node.js terminates the process. See: Nodejs does not wait for promise resolution - exits instead nodejs/node#22088

I did have a chat about supporting async logic in lifecycle hook with @AndrewKushnir and we will discussion this more next week.

In both cases, the errors are uncaughtException, maybe we can add a listener and pass these to the global error handler instead.

[moonseob]

Thanks @alan-agius4,
I appreciate your detailed and helpful explanation.
During the reproduction process, I was also able to confirm that these errors were indeed ignored until zone.js 0.13.0.

May I ask for advice on figuring out a workaround?

---

With your comment, now I'm trying to mitigate the issues on my project.
I first discovered this behavior not in a lifecycle hook, but in router's resolve/canActivate.

const resolver: ResolveFn<any> = (route, state) => {
  // any of those statements will make the server eventually crash
  return throwError(() => ''); // [1]
  return new Promise((_, reject) => reject('')); // [2]
  return await new Promise((_, reject) => reject('')); // [3]
  throw new Error(''); // [4]
};

ResolveFn is allowed to be either sync or async, thus should have nothing to do with the floating promises.
After some basic debugging, to my understanding, any return value of ResolveFn will eventually turn into an Observable by wrapIntoObservable(), which kind of makes sense.
However, this was not the case with the statement [4], which crashed at the stage of closestInjector.runInContext(), even before wrapIntoObservable() kicks in.

Is there an effective way I can avoid crashing the server when an error is thrown either in a resolveFn or canActivateFn, other than catching all the exceptions?
Or is it just that they are never meant to throw an error in the first place, making it an Angular Universal pitfall here?

[alan-agius4]

All of the above ResolveFn cases will cause an unhandledRejection, because the router currently has some floating promise. The culprit of this problem is the below which returns a Promise that is unhandled. Which are no longer intercepted by zone.js and thus not passed to the ErrorHandler.

angular/packages/router/src/router.ts

Line 417 in 3a05e4c

this.scheduleNavigation(urlTree, source, restoredState, extras);

In the mean time as an interim workaround, you can place the below code in your server.ts

process.on('uncaughtException', (err, origin) => {
  console.error(err)
});