Possible regression with newest AngularNodeAppEngine in @angular/ssr (19.0.0-next.11)

[riccardoperra]

Command

build, serve

Is this a regression?

• Yes, this behavior used to work in the previous version

The previous version in which this bug was not present was

No response

Description

I created 2 folders in the repository to show use cases that are no longer working

Previously, in <=18 angular applications, we were able to pass providers into the CommonEngine options. This allowed to propagate values via injection token retrieved in server.ts to the application.

Not knowing if there is a better approach, those values usually are:

• configurations that must be available also in the angular application. Those values are always present during SSR and sometimes are needed also on the browser, so TransferState is needed to propagate them
  • app.config.ts : example of a token always valuated in both ssr and browser
• server only object that allow to update the request data (e.g. update response headers / status code) / redirect
  • Main use cases are for example the possibility to change the page status to 404 if the requested resource does not exist, preserving navigation.
• static values that must be fetched only on server bootstrap and reused across all requests.

An important use case is that those value could be used into other application-level providers, in order to configurate them based on the request providers.

With the new AngularAppEngine in v19, I saw from @JeanMeche reproduction that you can pass custom values into the requestContext parameter when you render the app (server.ts), however I have noticed some unusual behaviors that make me think I can't do the same things:

• Those values are not always valuated. It seems that there is a case (the first request?) where those values are null.

Like the screenshot above, (reproducible with npm run start into the v19-ssr folder), after the server, the log just show that the first request invoke 2 time the application bootstrap: the first time values in request context (inject via REQUEST_CONTEXT token) are null, the second one are valuated. This is critical since the first time an error is thrown, the application breaks.

• Cannot modify request headers/status: with the new native Response object, it seems that we are not allowed anymore to update it imperatively into the angular application. Example

Minimal Reproduction

https://github.com/riccardoperra/angular-ssr-repro

Exception or Error

No response

Your Environment

     _                      _                 ____ _     ___
    / \   _ __   __ _ _   _| | __ _ _ __     / ___| |   |_ _|
   / △ \ | '_ \ / _` | | | | |/ _` | '__|   | |   | |    | |
  / ___ \| | | | (_| | |_| | | (_| | |      | |___| |___ | |
 /_/   \_\_| |_|\__, |\__,_|_|\__,_|_|       \____|_____|___|
                |___/
    

Angular CLI: 19.0.0-next.13
Node: 22.2.0
Package Manager: npm 10.7.0
OS: darwin arm64

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

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1900.0-next.13 (cli-only)
@angular-devkit/build-angular   19.0.0-next.13
@angular-devkit/core            19.0.0-next.13 (cli-only)
@angular-devkit/schematics      19.0.0-next.13 (cli-only)
@angular/cli                    19.0.0-next.13
@angular/ssr                    19.0.0-next.13
@schematics/angular             19.0.0-next.13 (cli-only)
rxjs                            7.8.1
typescript                      5.6.3
zone.js                         0.15.0
    

Anything else relevant?

No response

[alan-agius4]

Providers are intentionally not added directly in server.ts by design, as discussed in the RFC. Instead, they should be defined within app.config.server.ts. To work with RESPONSE and REQUEST, use the designated DI tokens.

Before (in server.ts)

const apiUrl = req.header('x-gw-url') ?? 'http://localhost:3000';

commonEngine.render({
  bootstrap,
  documentFilePath: indexHtml,
  url: `${protocol}://${headers.host}${originalUrl}`,
  publicPath: browserDistFolder,
  providers: [
    { provide: APP_BASE_HREF, useValue: baseUrl },
    { provide: API_URL, useValue: apiUrl },
    {
      provide: SSR_ONLY_UPDATE_STATUS_HANDLER,
      useValue: (code: number) => res.status(code),
    },
  ],
});

Now (in app.config.server.ts)

const serverConfig: ApplicationConfig = {
  providers: [
    provideServerRendering(),
    provideServerRoutesConfig(serverRoutes),
    {
      provide: API_URL,
      useFactory: () => {
        const req = inject(REQUEST, { optional: true});
        return req?.headers.get('x-gw-url') ?? 'http://localhost:3000';
      },
    },
    {
      provide: SSR_ONLY_UPDATE_STATUS_HANDLER,
      useFactory: () => {
        const res = inject(RESPONSE_INIT, { optional: true});
        return (code: number) => {
           if (res) {
              res.status = code;
           }
        };
      },
    },
  ],
};

[riccardoperra]

Thanks for the clear explaination @alan-agius4.

I just have a doubt with the REQUEST_CONTEXT token. Is it right that it could be ``null`?

The ideal case for us is to use it to load additional information that we want to retrieve inside the bootstrap (one-time only) but the fact that it is not always valued would imply the management of potential cases where it is null (which normally shouldn't).

I can't understand why, since it's a static value you pass into the render method, the first request this value is not valuated.

[alan-agius4]

REQUEST_CONTEXT, REQUEST, and REQUEST_INIT may all be null. During the initial build or bootstrap of the application, a manifest is generated by running the app without any request data. This process extracts routes and other essential information from the application, which also applies to prerendering. Therefore, assuming these values will always be defined is incorrect and considered a bad practice.

If you want to load specific data for reuse across multiple requests, the simplest method is to fetch this data during the and save it in a global cache.

let cachedInfo;

const serverConfig: ApplicationConfig = {
  providers: [
    {
      provide: MY_TOKEN,
      useFactory: () => {
        return cachedInfo ?? (cachedInfo = { foo: 1 });
      },
    },
  ],
};

The requestContext should typically be utilized by hosting providers to supply additional request information that isn’t included in the standard request, such as geographic location and other relevant details.

[angular-automatic-lock-bot]

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

_{This action has been performed automatically by a bot.}