Angular SSR/Hydration: Unexplained Third Execution of Initializer/Hooks on Server

[mmart1n]

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

Don't known / other

Is this a regression?

No

Description

🚀 Angular SSR/Hydration: Unexplained Third Execution of Initializer/Hooks on Server

Hello,

I am working on an Angular 20 project with Server-Side Rendering (SSR) and Client Hydration enabled. I have noticed unusual behavior during the initial page load involving application initializers and component lifecycle hooks.

My Setup:

• Angular Version: 20.x.x
• SSR: Enabled with Client Hydration (provideClientHydration())
• Data Fetching: A required HTTP request is initiated inside a function provided via provideAppInitializer() (or inside the AppComponent's constructor/ngOnInit).
• State Transfer: Configured correctly (the client is successfully reusing the first server response).

The Observed Behavior:

On a fresh page load, my logging shows that the root component's constructor, ngOnInit, and the provideAppInitializer callback are executed three times in the following sequence:

Execution Event	Environment	HTTP Request Made?	Expected Behavior?
1st Hook Run	Server (Node.js)	YES	Expected: Initial Server Render
2nd Hook Run	Browser (Client)	NO (Transferred)	Expected: Client Hydration
3rd Hook Run	Server (Node.js)	YES	UNEXPECTED

The Anomaly:

The most confusing part is the third execution, which occurs on the server again after the client has started the hydration process. This third execution triggers a second, redundant HTTP request from the server, causing unnecessary load.

• Total Hook/Initializer Runs: 3 (Server, Client, Server)
• Total HTTP Requests: 2 (Both from the Server)

My Question:

Is this triple execution and the resulting extra server-side HTTP call a known issue, or does it indicate an incorrect configuration or a deeper problem with how I am utilizing provideAppInitializer alongside modern Angular SSR and Hydration?

Thank you for any insight or guidance!

Please provide a link to a minimal reproduction of the bug

No response

Please provide the exception or error you saw

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

Anything else?

No response

[JeanMeche]

Could you please provide a reproduction so can have good understanding of your configuration/setup.

[mmart1n]

export const appConfig: ApplicationConfig = {
  providers: [
    provideBrowserGlobalErrorListeners(),
    importProvidersFrom(ServiceWorkerModule.register('ngsw-worker.js', { enabled: process.env['ZHIK_ENV'] === 'production' })),
    provideZoneChangeDetection({ eventCoalescing: true }),
    provideRouter(
      appRoutes,
      withInMemoryScrolling({
        scrollPositionRestoration: 'top'
      }),
      withPreloading(PreloadAllModules),
      withComponentInputBinding()
    ),
    provideClientHydration(withEventReplay(), withI18nSupport()),
    provideAppInitializer(() => {
      const platformDataService = inject(PlatformDataService);
      if(platformDataService.isServer) {
        console.log('call http call');
      }
    }),
    provideAnimationsAsync(),
    provideAnimations(),
    {
      provide: MAT_TOOLTIP_SCROLL_STRATEGY,
      useFactory: (scrollStrategyOptions: ScrollStrategyOptions) => scrollStrategyOptions.close,
      deps: [ScrollStrategyOptions]
    },
    provideDateFnsAdapter(DATE_BG_FORMATS),
    { provide: DateAdapter, useClass: DateFnsAdapter, deps: [MAT_DATE_LOCALE] }
  ],
};

[JeanMeche]

We'd like a working repro in the form of a stackblitz or a github repo. This config isn't enough to investigate your report.

[mmart1n]

Thanks for looking into this.

I was able to narrow down the root cause of the issue while preparing the sample. It’s triggered by the wildcard route (**) defined in app.routes.ts, which follows the pattern suggested in the Angular docs for displaying a 404 page:
https://angular.dev/guide/routing/common-router-tasks#displaying-a-404-page

To reproduce the behavior using the attached minimal project, run:

npm run build
npm run serve:ssr:angular-19-ssr

Removing the wildcard route prevents the issue from occurring.

angular-19-ssr.zip

[alan-agius4]

The second request is directed to http://localhost:4000/.well-known/appspecific/com.chrome.devtools.json. Because the ** wildcard is enabled, this call is being intercepted and routed to Angular.

NB: this only happens when devtools are open.