WEB-965: use parsed errorBody consistently in ErrorHandlerInterceptor

[RiteshGite]

Description

Prevents runtime crashes in ErrorHandlerInterceptor when handling malformed or ArrayBuffer-based API error responses.

This change updates the interceptor to consistently use the parsed errorBody instead of directly accessing response.error. It also safely handles nullable error fields using optional chaining and preserves fallback error message behavior.

This fixes cases where the global error handler could fail when:

• API errors were returned as ArrayBuffer
• errors[0] was missing
• defaultUserMessage or developerMessage was null/undefined

---

Related Issues and Discussion

#WEB-965

---

Reproduction Steps

To validate the unsafe cases, the interceptor's intercept() method was temporarily modified to force specific error payloads.

Scenario 1: Empty errors array

Temporary code used

intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
  return throwError(() =>
    new HttpErrorResponse({
      status: 400,
      url: request.url,
      error: { errors: [] }
    })
  ).pipe(catchError((error) => this.handleError(error, request)));
}

Expected issue before fix: Runtime error when the code tries to access errorBody.errors[0].

---

Scenario 2: null defaultUserMessage

Temporary code used

intercept(request: HttpRequest<any>, next: HttpHandler): Observable<HttpEvent<any>> {
  return throwError(() =>
    new HttpErrorResponse({
      status: 400,
      url: request.url,
      error: {
        errors: [{
          defaultUserMessage: null,
          developerMessage: "Detailed logs"
        }]
      }
    })
  ).pipe(catchError((error) => this.handleError(error, request)));
}

Expected issue before fix: Runtime error when .replace() is called on null.

---

Screenshots & Videos

Before Fix

1. Empty errors array — crash

EmptyArray.mp4

2. Null defaultUserMessage — crash

nullError.mp4

After Fix

1. Empty errors array — handled gracefully

EmptyArray_Error_Handled.mp4

2. Null defaultUserMessage — handled gracefully

Null_Error_Handled.mp4

3. Error handler working correctly

Final_Output_With_Original_Intercepter_And_Updated_Error_Handler.mp4

---

Checklist

Please make sure these boxes are checked before submitting your pull request — thanks!

• If you have multiple commits please combine them into one commit by squashing them.
• Read and understood the contribution guidelines at web-app/.github/CONTRIBUTING.md.

[coderabbitai]

Note

.coderabbit.yaml has unrecognized properties

CodeRabbit is using all valid settings from your configuration. Unrecognized properties (listed below) have been ignored and may indicate typos or deprecated fields that can be removed.

⚠️ Parsing warnings (1)

Validation error: Unrecognized key: "pre_merge_checks"

⚙️ Configuration instructions

• Please see the configuration documentation for more information.
• You can also validate your configuration using the online YAML validator.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json

Walkthrough

This PR refactors the error-handler interceptor's message-derivation logic to use safer optional chaining on parsed errorBody, improve database-integrity code detection via array includes(), and normalize messages by replacing dots with spaces. The single-file change affects how HTTP error responses map to user-facing error messages.

Changes

Error Handler Message Derivation

Layer / File(s)	Summary
Error message extraction and normalization src/app/core/http/error-handler.interceptor.ts	Lines 95–106 refactor errorMessage derivation from errorBody.errors[0] with safer optional chaining on defaultUserMessage/developerMessage; database-integrity detection now uses includes() to check userMessageGlobalisationCode and translates matching codes to a fixed integrity-issue message; non-integrity paths clean up messages by replacing dots with spaces via regex.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Possibly related PRs

• openMF/web-app#3452: Both PRs modify src/app/core/http/error-handler.interceptor.ts to refine how errorMessage is derived from HTTP error payloads using userMessageGlobalisationCode and errorBody.errors[0].

Suggested reviewers

• alberto-art3ch

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Title check	✅ Passed	The title 'WEB-965: use parsed errorBody consistently in ErrorHandlerInterceptor' accurately summarizes the main change: using parsed errorBody instead of response.error in the error handler.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[IOhacker]

Could you please add an evidence of the change?

[alberto-art3ch]

LGTM

[RiteshGite]

@IOhacker Added evidence for the reported issue along with before/after screenshots. Please review again. Thanks!

[Flashl3opard]

@RiteshGite Thanks for adding the evidence videos. Could you also add an after-fix video for the same scenarios instead of only a screenshot?

Right now, the screenshot does not clearly demonstrate:

• The same malformed payload was triggered
• The interceptor actually handled the error path safely
• The fallback message behavior worked as expected

A short validation recording covering the same cases after the fix would make verification much clearer for reviewers.

[RiteshGite]

@Flashl3opard Added after-fix validation videos for the same scenarios as requested. Please take a look when you get a chance. Thanks!