AngularNodeAppEngine: Injected REQUEST empty on first initialization

[MarcoGlauser]

Command

run

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

We're in the process of moving from angular 18 with the webpack ssr builder to the angular 19 application builder with server routes, since request and response objects are now supported for dev builds.
However, we started getting a lot of errors during the first page load after starting a dev server.
It looks like on the start of the dev server, the first request injects a value of null for the REQUEST provider.

Minimal Reproduction

I've created a reproduction here:
https://github.com/MarcoGlauser/angular-19-ssr-request
https://stackblitz.com/github/MarcoGlauser/angular-19-ssr-request

When starting the server, the server console will output the following on the first page load, as if it's rendering the application twice:

provided request is null true
provided request is null false

The response that is sent to the browser seems to be from the second pass, but the first pass causes a lot of errors in our codebase, since we're expecting the request to be set for all SSR requests.

Exception or Error

Your Environment

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

Angular CLI: 19.0.2
Node: 22.11.0
Package Manager: npm 10.9.0
OS: linux x64

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

Package                         Version
---------------------------------------------------------
@angular-devkit/architect       0.1900.2
@angular-devkit/build-angular   19.0.2
@angular-devkit/core            19.0.2
@angular-devkit/schematics      19.0.2
@angular/cli                    19.0.2
@angular/ssr                    19.0.2
@schematics/angular             19.0.2
rxjs                            7.8.1
typescript                      5.6.3
zone.js                         0.15.0

Anything else relevant?

No response

[alan-agius4]

This is expected and working as intended. See: https://angular.dev/guide/hybrid-rendering#accessing-request-and-response-via-di

[MarcoGlauser]

I see, thank you! I guess this is part of "route extraction".
Is there any more information on the route extraction during the dev server startup? Is there a way to detect it, similar to isPlatformServer?
From what I can tell, reading the source code, route extraction is only required for prerendering. But we're running only server rendering, without any prerendering.
Sorry for all the questions, I'm just genuinely confused by this new mode and how we can move our existing functionality (cookie parsing, redis caching, proxies) to the new server mode.

[alan-agius4]

Is there any more information on the route extraction during the dev server startup? Is there a way to detect it, similar to isPlatformServer?

Not really, what is your use case though? In general I'd say that checks like isPlatformServer, isPlatformServer should be avoided.

From what I can tell, reading the source code, route extraction is only required for prerendering. But we're running only server rendering, without any prerendering.

The application will be bootstrapped during the build process to validate and extract all routes, generating an SSR manifest. In the future, file-based routing may address this issue. If this does not happen during build time this would need to be done during the first request which wall cause slow it down and may cause validation errors to appear at runtime instead of during the build process.

[MarcoGlauser]

Thank you, that makes sense :)

Since we injected the request and response objects manually, we could rely on them always being present.
By adding null checks, we're able to get rid of the error messages during route extraction but it also swallows potential configuration errors.
The request and response objects were injected/routed through quite a few layers in the past. Having them throw an error if they're not present actually saved us from shipping a broken configuration before. I guess now that the whole thing is part of angular proper, we don't need the custom plumbing anymore and the risk of a broken config is not that big anymore.

Overall, we're really happy with the direction of angular ssr. It's just that we're running teething issues of moving an existing ssr project to the new paradigm. We originally started with Angular 9 that we upgraded and migrated up until now. So there is a lot of accumulated custom cruft in the node/ ssr part because ssr was neglected for such a long time.

In general I'd say that checks like isPlatformServer, isPlatformServer should be avoided.

While I agree in theory, we have them all over the place because node and browser apis are too different.
If you're interested, I can go through our codebase and make a list of examples.

[alan-agius4]

In general replace a service/token value with DI is a the recommended approach. See: angular/angular#53168

[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.}