Vite dev server crashes when HttpClient receives non-200 code

[zip-fa]

Command

serve

Is this a regression?

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

The previous version in which this bug was not present was

v17

Description

Basically, it's a duplicate of https://github.com/angular/angular-cli/issues/26192

But now it's here again with v19, zoneless and outputMode: 'server'. Is this behaviour expected and not-an-issue on new setup?

Minimal Reproduction

ng serve

Exception or Error

No response

Your Environment

HttpErrorResponse

Anything else relevant?

No response

[alan-agius4]

This is a known issue with zoneless, and it not limited to dev-servers.

[zip-fa]

In prod env, server will crash too? Is there any catch error mechanism that can be applied to not stop dev/prod app, but respond with 500 code?

[alan-agius4]

Yes, in the production environment, the server will crash because zone.js is not intercepting and handling unhandled errors and rejections.

Since the error is "unhandled," the request's lifecycle will continue in this scenario. For a potential workaround, please refer to https://github.com/angular/angular-cli/pull/28405

[alan-agius4]

Moving to the FW repo as following the convo in https://github.com/angular/angular-cli/pull/28405#discussion_r1791871459 the FW should handle the errors.

[patricsteiner]

This is quite annoying... Catching all node errors globally seems not to be the right solution, as discussed in https://github.com/angular/angular-cli/pull/28405#discussion_r1791871459. Is there no recommended approach on how to handle these errors? For now I am using a global interceptor that just returns EMPTY on error. This is still quite bad, since it leaves the app in an unexpected state that likely needs a page refresh to work again, but at least the server does not crash.

export const httpErrorInterceptor: HttpInterceptorFn = (req, next) => {
  const toast = inject(ToastService)
  return next(req).pipe(
    catchError((err) => {
      console.error(err);
      toast.show("HTTP Error: " + err.message)
      return EMPTY;
    }),
  );
};

[zip-fa]

This is quite annoying... Catching all node errors globally seems not to be the right solution, as discussed in angular/angular-cli#28405 (comment). Is there no recommended approach on how to handle these errors? For now I am using a global interceptor that just returns EMPTY on error. This is still quite bad, since it leaves the app in an unexpected state that likely needs a page refresh to work again, but at least the server does not crash.

export const httpErrorInterceptor: HttpInterceptorFn = (req, next) => { const toast = inject(ToastService) return next(req).pipe( catchError((err) => { console.error(err); toast.show("HTTP Error: " + err.message) return EMPTY; }), ); };

Returning EMPTY or catching error project-wide will break rxResource. It’s better to move all your GET requests to rxResource and remove your project-wide error interceptor

[patricsteiner]

Returning EMPTY or catching error project-wide will break rxResource. It’s better to move all your GET requests to rxResource and remove your project-wide error interceptor

That would work I guess, but refactoring all http requestrs to use rxResource would be quite a hassle.

[angular-automatic-lock-bot[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.}