fix(platform-server): propagate errors from lifecycle hooks when utilizing platform-server

[alan-agius4]

In previous versions, if an error occurred within the lifecycle hooks, the promises for renderModule and renderApplication were not rejected. This could result in serving a "broken" page during Server-Side Rendering (SSR), or the build erroneously being marked as successful during Static Site Generation (SSG).

Fixes #33642

[pawelfras]

Hey @alan-agius4,
I appreciate your work and the fact that the Angular Core team has started working on Error handling in SSR/SSG! I would like to ask about two topics:

• It may be beyond the scope of this PR, but how to trade HTTP errors from the backend? Make a custom HTTP interceptor that catches all backend HTTP errors and then calls ErrorHandler.handleError(HTTP error response). Such a kind of errors should also be handled so that in the end the user doesn't receive with high certainty malformed HTML with wrong status 200
• What is the advantage of emitting a rejection of the promise whenStableWithoutError immediately, not only when the app is stable? In such a scenario, HTTP requests may still exist as 'stabilisation' is in progress. In both SSR and SSG.

I hope you don't mind that I added this comment directly to this PR.

Best regards!

[Platonn]

Hi @alan-agius4

Did you consider making the ErrorInterceptor public and extendable? Our use case is to capture the application's state (e.g. get data from the ngrx store via DI, or any other context from DI) and attach it as a context to the propagated error. Thanks to this context, we'll be able to better handle this error in the ExpressJS layer, where the Angular DI context is unavailable. For example, based on the additional context attached to the propagated error object, in ExpressJS we can set an appropriate HTTP error status code for the response to the client, e.g. 404 vs 500.

The BEFORE_APP_SERIALIZED is the hook of the "last moment" allowing to access Angular DI and modify the final HTML markup (e.g. attaching the TransferState).

Analogically, we need the hook of "last moment" allowing to access DI and modify the final error (or returning a brand new error object - use case: return a custom "wrapper Error object" with the cause property pointing to the original error)

If you don't want to expose in the public API the whole ErrorInterceptor, we could at least expose the injection token hook in @angular/platform-server, e.g. new InjectionToken<(error: unknown) => unknown>, maybe named as BEFORE_ERROR_PROPAGATED.