Skip to content

Conversation

@AnvayKharb
Copy link
Contributor

@AnvayKharb AnvayKharb commented Nov 22, 2025

Implemented a centralized ErrorHandlerService to unify, standardize, and simplify error and success messaging across the application. This update replaces inconsistent, scattered error-handling logic in multiple components with a single reusable service. The new handler converts HTTP status codes into clear, user-friendly messages, extracts meaningful Fineract-specific error details, and displays all notifications using consistent Angular Material snackbars. Additionally, the service now supports client-side/network error detection, success notifications, and informational messages, ensuring a consistent and polished user experience throughout the app. All affected components were refactored to use the new service, reducing code duplication and improving maintainability. This enhancement prevents raw backend errors from being exposed to users, improves clarity, and provides a unified approach to handling failures and confirmations.

#Issue Number

WEB-429

Screenshots, if any
N/A

Summary by CodeRabbit

  • New Features

    • App-wide centralized error handling with contextual, user-facing HTTP error notifications and automatic sign-in action on authentication errors
    • Unified success and informational notifications with consistent actions and visuals
  • Documentation

    • Comprehensive README detailing usage patterns, customization, migration, testing, and best practices
  • Style

    • New snackbar styles for error, success, and info notifications

✏️ Tip: You can customize this high-level summary in your review settings.

@coderabbitai
Copy link

coderabbitai bot commented Nov 22, 2025

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(s) in object: '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

Adds a singleton Angular ErrorHandlerService that converts HttpErrorResponse and client/network errors into structured messages, displays Material snackbars for error/success/info, optionally navigates to login on 401 action, includes SCSS snackbar variants, and adds a README documenting usage and API.

Changes

Cohort / File(s) Summary
Error Handler Service & API
src/app/core/error-handler/error-handler.service.ts
Adds ErrorMessage interface and ErrorHandlerService (providedIn: 'root') with handleError(error: HttpErrorResponse, context?: string): Observable<never>, showSuccess(message, action?), showInfo(message, action?); maps HTTP statuses (400, 401, 403, 404, 409, 500, 503), parses server payloads and client/network errors to structured messages; opens MatSnackBar with contextual panel classes and triggers Router navigation for 401 actions.
Documentation
src/app/core/error-handler/README.md
Adds README documenting service overview, usage examples (basic, with context, success/info), advanced usage, styling, API reference, Fineract integration guidance, migration notes, testing guidance, and contribution notes.
Styling — component
src/app/core/error-handler/error-handler.component.scss
Adds SCSS defining .error-snackbar, .success-snackbar, and .info-snackbar variants targeting Material/ MDC snackbar label/action/button selectors; sets background/text colors and positioning/display hints.
Styling — global import
src/main.scss
Adds import to include error-handler styles globally (@use 'app/core/error-handler/error-handler.component'; with comment).

Sequence Diagram(s)

sequenceDiagram
    participant Comp as Caller (Component/Service)
    participant EH as ErrorHandlerService
    participant MS as MatSnackBar
    participant RT as Router

    rect rgb(255,250,250)
    alt Error flow
        Comp->>EH: handleError(error, context?)
        EH->>EH: getErrorMessage(error, context)
        EH-->>MS: open(title + message, action?, {panelClass: 'error-snackbar', duration})
        alt 401 & action clicked
            User-->>MS: clicks action
            MS->>RT: navigate('/login')
        end
        EH-->>Comp: rethrow error (Observable<never>)
    end
    end

    rect rgb(240,255,240)
    alt Success / Info flow
        Comp->>EH: showSuccess(msg, action?) / showInfo(msg, action?)
        EH-->>MS: open(msg, action?, {panelClass: 'success-snackbar'/'info-snackbar', duration})
        MS-->>Comp: notification displayed
    end
    end
Loading

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~25 minutes

  • Verify HTTP status → message mappings and server payload parsing for sensitive data exposure.
  • Confirm handleError preserves and rethrows the original error Observable semantics.
  • Review 401 handling: snackbar action callback wiring and Router navigation behavior.
  • Validate SCSS selectors match the Material/MDC snackbar structure and that the @use path in src/main.scss resolves in the build.

Pre-merge checks and finishing touches

✅ Passed checks (3 passed)
Check name Status Explanation
Description Check ✅ Passed Check skipped - CodeRabbit’s high-level summary is enabled.
Title check ✅ Passed The title directly and accurately summarizes the main change: implementing a centralized error handler service for user-friendly API error messaging, which aligns with all four files changed (README, service implementation, styling, and main.scss import).
Docstring Coverage ✅ Passed No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

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

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

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

🧹 Nitpick comments (3)
src/main.scss (1)

633-678: Snackbar styling looks correct; consider extracting shared rules.

The three variants correctly target the snackbar container and inner label/action/button elements and align with the intended colors. Since the inner selectors are identical across .error-snackbar, .success-snackbar, and .info-snackbar, you could optionally DRY this up with a mixin or placeholder to ease future maintenance.

src/app/core/error-handler/README.md (1)

51-149: Clarify handleError’s primary usage pattern with catchError.

The examples currently mix catchError((error) => this.errorHandler.handleError(error)) with direct subscribe(..., error => this.errorHandler.handleError(error)). Since handleError both shows a snackbar and returns a throwError observable, it may help to explicitly recommend the catchError pattern as the default and note that, when using it from a plain subscribe error callback, the returned observable is intentionally ignored. This will keep RxJS usage consistent across the codebase.

src/app/core/error-handler/error-handler.service.ts (1)

59-124: Broaden network error handling beyond ErrorEvent to cover status === 0.

Currently connection issues are only recognized when error.error instanceof ErrorEvent. Angular can also surface network/offline failures as HttpErrorResponse with status === 0 and a non‑ErrorEvent payload, which would then fall through to the generic “Error” case. To better match the documented “Network Error → Connection Error” behavior, consider treating status === 0 as a connection error too, e.g.:

-  private getErrorMessage(error: HttpErrorResponse, context?: string): ErrorMessage {
-    if (error.error instanceof ErrorEvent) {
+  private getErrorMessage(error: HttpErrorResponse, context?: string): ErrorMessage {
+    if (error.error instanceof ErrorEvent || error.status === 0) {
       // Client-side or network error
       return {
         title: 'Connection Error',
         message: 'Unable to connect to the server. Please check your internet connection.',
         action: 'Retry'
       };
     }

This keeps user messaging consistent for all network failures.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1ef4de5 and ee205e6.

📒 Files selected for processing (3)
  • src/app/core/error-handler/README.md (1 hunks)
  • src/app/core/error-handler/error-handler.service.ts (1 hunks)
  • src/main.scss (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
src/app/**

⚙️ CodeRabbit configuration file

src/app/**: For Angular code: verify component separation, trackBy on *ngFor,
strict type safety, and clean observable patterns.

Files:

  • src/app/core/error-handler/error-handler.service.ts
  • src/app/core/error-handler/README.md
🪛 LanguageTool
src/app/core/error-handler/README.md

[grammar] ~5-~5: Use a hyphen to join words.
Context: ...orHandlerService` is a centralized error handling solution for the Mifos X Web Ap...

(QB_NEW_EN_HYPHEN)


[grammar] ~21-~21: Ensure spelling is correct
Context: ...components - Better UX with appropriate snackbar notifications ## Features ### 1. HTTP...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Run Lint, Build and Deploy
🔇 Additional comments (1)
src/app/core/error-handler/error-handler.service.ts (1)

145-166: Success/info snackbar helpers are consistent with docs and styles.

showSuccess and showInfo use clear defaults, appropriate durations/positions, and the panelClass values line up with both the README and main.scss. Centralizing these helpers should significantly reduce duplicated snackbar config in components.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 2

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ee205e6 and 6a7a29e.

📒 Files selected for processing (2)
  • src/app/core/error-handler/README.md (1 hunks)
  • src/app/core/error-handler/error-handler.service.ts (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
src/app/**

⚙️ CodeRabbit configuration file

src/app/**: For Angular code: verify component separation, trackBy on *ngFor,
strict type safety, and clean observable patterns.

Files:

  • src/app/core/error-handler/error-handler.service.ts
  • src/app/core/error-handler/README.md
🪛 LanguageTool
src/app/core/error-handler/README.md

[grammar] ~21-~21: Ensure spelling is correct
Context: ...components - Better UX with appropriate snackbar notifications ## Features ### 1. HTTP...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Run Lint, Build and Deploy
🔇 Additional comments (9)
src/app/core/error-handler/error-handler.service.ts (4)

1-39: LGTM! Clean service setup with proper typing.

The service structure is well-organized with appropriate imports, a clear ErrorMessage interface, and proper dependency injection of MatSnackBar. The singleton pattern via providedIn: 'root' is the correct choice for this centralized service.


47-51: LGTM! Proper error handling flow.

The method correctly displays user-friendly errors while rethrowing the original error via throwError(() => error), allowing upstream handlers to still process the error if needed.


69-124: Excellent Fineract error extraction and status code coverage.

The optional chaining at lines 70-71 safely extracts Fineract-specific error messages, and the switch statement comprehensively handles all major HTTP status codes with user-friendly titles and messages. The prioritization of fineractError || defaultMessage || fallback ensures users see meaningful error details when available.


157-178: LGTM! Well-designed notification methods.

The showSuccess and showInfo methods use appropriate durations (3s and 4s respectively) and bottom positioning for non-critical messages, distinguishing them from error notifications (5s, top). The default action parameter values and panel classes ensure consistent UX.

src/app/core/error-handler/README.md (5)

1-22: LGTM! Clear overview with accurate problem statement.

The overview effectively explains the service's purpose and value proposition. Note: The static analysis tool's warnings about "error-handling" and "snackbar" are false positives—"error-handling" is correctly hyphenated at line 5, and "snackbar" is standard Angular Material terminology.


23-50: Accurate documentation of service features.

The supported error codes table (lines 34-43) and notification types (lines 47-49) accurately reflect the implementation, including the durations (5s for errors, 3s for success, 4s for info) and positioning (top-center for errors, bottom-center for success/info).


51-109: Excellent usage examples with proper RxJS patterns.

The examples demonstrate proper Angular/RxJS patterns using pipe() and catchError(), and the import path @core/error-handler/error-handler.service follows Angular path alias conventions. The progression from basic to contextual usage is clear and helpful.


163-216: API reference accurately documents the service interface.

The method signatures, parameters, and return types documented here precisely match the implementation in error-handler.service.ts. The examples for each method clearly demonstrate usage.


218-349: Comprehensive documentation covering integration, migration, and testing.

The Fineract error extraction priority (lines 232-236) correctly documents the implementation logic (errors[0].defaultUserMessagedefaultUserMessage → fallback). The migration guide clearly demonstrates the improvement over previous error handling, and the testing example provides a solid foundation for unit tests.

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (3)
src/app/core/error-handler/error-handler.service.ts (3)

73-75: Consider adding a type interface for Fineract error structure.

The optional chaining safely handles the nested error structure, but defining an explicit interface for the expected Fineract error response would improve type safety and documentation:

interface FineractErrorResponse {
  errors?: Array<{ defaultUserMessage?: string }>;
  defaultUserMessage?: string;
}

Then type the error parameter or cast appropriately when accessing error.error. This would make the expected API contract clearer for future maintainers.


77-128: Comprehensive HTTP status mapping with appropriate fallbacks.

The status code handling covers common scenarios well, with proper Fineract error extraction and sensible fallback messages. The context parameter is thoughtfully used for 404 errors to provide specific resource context.

One optional enhancement: Consider utilizing context for other status codes (e.g., "Failed to ${context}" for 500 errors) to provide more specific user feedback across all error types, not just 404s.


160-181: Success and info methods are well-implemented with appropriate configurations.

The different durations (3s for success, 4s for info) and positioning (bottom for less intrusive notifications vs. top for errors) provide good UX differentiation.

The methods don't return MatSnackBarRef, which keeps the API simple but means consumers can't react to dismissal or custom actions. This is likely intentional for the centralized handler pattern, but if advanced scenarios require access to snackbar lifecycle events, consider optionally returning the ref.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 6a7a29e and fd7a967.

📒 Files selected for processing (1)
  • src/app/core/error-handler/error-handler.service.ts (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
src/app/**

⚙️ CodeRabbit configuration file

src/app/**: For Angular code: verify component separation, trackBy on *ngFor,
strict type safety, and clean observable patterns.

Files:

  • src/app/core/error-handler/error-handler.service.ts
🧬 Code graph analysis (1)
src/app/core/error-handler/error-handler.service.ts (1)
src/app/core/logger/logger.service.ts (1)
  • error (100-102)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Run Lint, Build and Deploy
🔇 Additional comments (4)
src/app/core/error-handler/error-handler.service.ts (4)

19-29: Well-structured imports and interface.

The imports are appropriate and the ErrorMessage interface is clean and properly exported for potential consumer use. The optional action field provides flexibility for different error scenarios.


40-43: Constructor properly implements dependency injection.

The service correctly injects MatSnackBar for UI notifications and Router for navigation (addressing previous feedback about using SPA routing instead of page reloads).


51-55: Correct error handling pattern with proper error propagation.

The method correctly displays user-friendly messages while preserving the original error for upstream handling. The Observable<never> return type and throwError(() => error) factory pattern align with RxJS 7 best practices.


135-153: Login action properly implemented using Angular Router.

The snackbar configuration is appropriate, and the 'Login' action now correctly uses router.navigate(['/login']) instead of a full page reload, preserving SPA benefits and addressing previous review feedback.

The onAction() subscription doesn't need explicit cleanup since MatSnackBar completes the observable when dismissed.

@AnvayKharb
Copy link
Contributor Author

@gkbishnoi07 Please review this

@AnvayKharb AnvayKharb force-pushed the WEB-429-implement-centralized-error-handler-service-for-user-friendly-api-error-messaging branch from fd7a967 to 346ccf5 Compare November 22, 2025 17:05
@AnvayKharb
Copy link
Contributor Author

@alberto-art3ch @steinwinde please review ..!

Copy link
Collaborator

@alberto-art3ch alberto-art3ch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please see my comment, and

Great job even with the documentation! I have a question, How It is triggered? I mean currently there is an error handler interceptor, If you have screenshots please add them in the PR details

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (2)
src/app/core/error-handler/error-handler.component.scss (1)

28-83: Refactor repetitive snackbar styling using SCSS mixin for DRY principle.

All three snackbar classes share identical selector structure and color-setting patterns. This can be consolidated using a SCSS mixin to reduce duplication, improve maintainability, and make future updates easier.

Here's a suggested refactor:

@mixin snackbar-variant($bg-color) {
  background-color: $bg-color !important;
  color: white !important;

  .mat-mdc-snack-bar-label,
  .mdc-snackbar__label,
  .mat-simple-snackbar-action {
    color: white !important;
  }

  .mat-mdc-button {
    color: white !important;
  }
}

.error-snackbar {
  @include snackbar-variant(#f44336);
}

.success-snackbar {
  @include snackbar-variant(#4caf50);
}

.info-snackbar {
  @include snackbar-variant(#2196f3);
}

This approach maintains the same rendering while eliminating duplication.

src/app/core/error-handler/README.md (1)

195-248: API Reference is clear; consider documenting return types explicitly.

The API Reference section provides good parameter documentation and examples. However, the showSuccess() and showInfo() method signatures could explicitly document their return type (void) for completeness, matching the explicit return type documentation for handleError().

Update lines 218 and 235 to clarify return types:

-#### `showSuccess(message: string, action?: string): void`
+#### `showSuccess(message: string, action?: string): void`

(The signature is already correct; this is simply a note to verify clarity.)

Alternatively, if you'd like to be more explicit in the narrative:

-Shows a success message to the user.
+Shows a success message to the user. Returns `void`.

This ensures consistency with how handleError() documents its return type at line 208.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 346ccf5 and dad9a89.

📒 Files selected for processing (3)
  • src/app/core/error-handler/README.md (1 hunks)
  • src/app/core/error-handler/error-handler.component.scss (1 hunks)
  • src/main.scss (1 hunks)
✅ Files skipped from review due to trivial changes (1)
  • src/main.scss
🧰 Additional context used
📓 Path-based instructions (1)
src/app/**

⚙️ CodeRabbit configuration file

src/app/**: For Angular code: verify component separation, trackBy on *ngFor,
strict type safety, and clean observable patterns.

Files:

  • src/app/core/error-handler/error-handler.component.scss
  • src/app/core/error-handler/README.md
🪛 LanguageTool
src/app/core/error-handler/README.md

[grammar] ~53-~53: Ensure spelling is correct
Context: ...components - Better UX with appropriate snackbar notifications ## Features ### 1. HTTP...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

🔇 Additional comments (1)
src/app/core/error-handler/README.md (1)

1-50: Documentation is comprehensive and well-organized; hyphenation from past review is resolved.

The README provides excellent coverage of the service, including clear examples, API reference, migration guide, and best practices. The hyphenation correction noted in the past review ("centralized error-handling service" at line 5) has been properly applied. Overall structure and content quality are solid for a new centralized service.

@AnvayKharb
Copy link
Contributor Author

@alberto-art3ch Thanks, Alberto! Quick update:

Error handling:
README now clarifies the difference — the interceptor handles all HTTP errors globally, while the new ErrorHandlerService is used in components (via catchError) for custom, context-specific messages.

Snackbar styles:
Moved from main.scss to error-handler.component.scss for cleaner organization.
Changes are in commit dad9a89.

@gkbishnoi07
Copy link
Collaborator

please squash your commit @AnvayKharb

@AnvayKharb AnvayKharb force-pushed the WEB-429-implement-centralized-error-handler-service-for-user-friendly-api-error-messaging branch from dad9a89 to 1b778b8 Compare November 30, 2025 07:56
@AnvayKharb
Copy link
Contributor Author

heyy @gkbishnoi07 I've just squashed my commits

Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 1

🧹 Nitpick comments (2)
src/app/core/error-handler/error-handler.service.ts (2)

63-129: Error mapping is comprehensive and user-friendly.

The error message mapping covers all common HTTP status codes with appropriate fallbacks. Fineract error extraction logic is well-implemented with proper optional chaining.

One optional enhancement to consider: integrating with the existing LoggerService (seen in the codebase) to log errors for debugging purposes. This would help with troubleshooting production issues without affecting the user experience.

For example:

  private getErrorMessage(error: HttpErrorResponse, context?: string): ErrorMessage {
+   // Log error for debugging
+   console.error('HTTP Error:', error);
+   
    if (error.error instanceof ErrorEvent) {

135-153: Error display and action handling implemented correctly.

The snackbar configuration is appropriate, and the 'Login' action now properly navigates using Angular Router (addressing previous review feedback). The onAction() subscription is safe without explicit unsubscribe because MatSnackBar completes its observables when the snackbar is dismissed.

Minor note for future extensibility: If additional action handlers are needed beyond 'Login', consider refactoring to a switch statement or action map pattern.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between dad9a89 and 1b778b8.

📒 Files selected for processing (4)
  • src/app/core/error-handler/README.md (1 hunks)
  • src/app/core/error-handler/error-handler.component.scss (1 hunks)
  • src/app/core/error-handler/error-handler.service.ts (1 hunks)
  • src/main.scss (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • src/app/core/error-handler/error-handler.component.scss
  • src/main.scss
🧰 Additional context used
📓 Path-based instructions (1)
src/app/**

⚙️ CodeRabbit configuration file

src/app/**: For Angular code: verify component separation, trackBy on *ngFor,
strict type safety, and clean observable patterns.

Files:

  • src/app/core/error-handler/error-handler.service.ts
  • src/app/core/error-handler/README.md
🧬 Code graph analysis (1)
src/app/core/error-handler/error-handler.service.ts (1)
src/app/core/logger/logger.service.ts (1)
  • error (100-102)
🪛 LanguageTool
src/app/core/error-handler/README.md

[grammar] ~53-~53: Ensure spelling is correct
Context: ...components - Better UX with appropriate snackbar notifications ## Features ### 1. HTTP...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Run Lint, Build and Deploy
🔇 Additional comments (6)
src/app/core/error-handler/error-handler.service.ts (3)

19-29: LGTM! Clean imports and well-defined interface.

The imports are minimal and appropriate, and the ErrorMessage interface provides clear structure for error messaging throughout the service.


36-55: LGTM! Proper service setup and error handling pattern.

The singleton pattern with providedIn: 'root' is correct, and the handleError method follows the proper RxJS pattern for use with catchError operators. The use of throwError(() => error) is compatible with RxJS 7+.


160-181: LGTM! Clean implementation of success and info notifications.

Both methods are straightforward and well-configured. The differentiation in duration and positioning (bottom for success/info vs. top for errors) provides good UX, making error notifications more prominent while keeping success/info messages less intrusive.

src/app/core/error-handler/README.md (3)

1-53: LGTM! Clear and accurate documentation introduction.

The overview and "How It Works" sections effectively explain the service's purpose and its relationship with the existing interceptor. The distinction between automatic (interceptor) and manual (service) error handling is particularly helpful for developers.

Note: The static analysis hint about "snackbar" spelling is a false positive—this is standard Material Design terminology.


55-141: Documentation accurately reflects the implementation.

The features table and usage examples are correct and comprehensive. All HTTP status codes, notification configurations (durations, positions, colors), and method signatures match the service implementation exactly.


195-297: API reference and integration guidance are accurate.

All method signatures, parameters, and return types match the service implementation. The Fineract error extraction logic is correctly documented with the proper priority order.

@AnvayKharb AnvayKharb force-pushed the WEB-429-implement-centralized-error-handler-service-for-user-friendly-api-error-messaging branch from 1b778b8 to 8c59c27 Compare November 30, 2025 08:11
Copy link

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (2)
src/app/core/error-handler/README.md (1)

199-214: Clarify 401 behavior in API reference.

The error codes table (line 69) indicates that 401 errors display "Session expired message," and the PR objectives mention that the service "optionally navigates to login on 401 action." However, the handleError() method documentation doesn't clearly explain this redirect side effect. This is important for developers to understand, since navigation is a side effect beyond just showing a message.

Consider updating the documentation to clarify whether the service automatically redirects to login on 401 responses, or if navigation is optional/configurable.

src/app/core/error-handler/error-handler.component.scss (1)

28-83: Consider SCSS mixin to reduce styling duplication.

The three snackbar classes (.error-snackbar, .success-snackbar, .info-snackbar) follow an identical structure with only the background color differing. This is a good candidate for refactoring using an SCSS mixin to improve maintainability and reduce duplication.

// Optional refactor suggestion:
@mixin snackbar-variant($bg-color) {
  background-color: $bg-color !important;
  color: white !important;

  .mat-mdc-snack-bar-label,
  .mdc-snackbar__label,
  .mat-simple-snackbar-action {
    color: white !important;
  }

  .mat-mdc-button {
    color: white !important;
  }
}

.error-snackbar {
  @include snackbar-variant(#f44336);
}

.success-snackbar {
  @include snackbar-variant(#4caf50);
}

.info-snackbar {
  @include snackbar-variant(#2196f3);
}

This reduces repetition while maintaining the same visual and behavioral output.

📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 1b778b8 and 8c59c27.

📒 Files selected for processing (4)
  • src/app/core/error-handler/README.md (1 hunks)
  • src/app/core/error-handler/error-handler.component.scss (1 hunks)
  • src/app/core/error-handler/error-handler.service.ts (1 hunks)
  • src/main.scss (1 hunks)
🚧 Files skipped from review as they are similar to previous changes (2)
  • src/app/core/error-handler/error-handler.service.ts
  • src/main.scss
🧰 Additional context used
📓 Path-based instructions (1)
src/app/**

⚙️ CodeRabbit configuration file

src/app/**: For Angular code: verify component separation, trackBy on *ngFor,
strict type safety, and clean observable patterns.

Files:

  • src/app/core/error-handler/error-handler.component.scss
  • src/app/core/error-handler/README.md
🪛 LanguageTool
src/app/core/error-handler/README.md

[grammar] ~53-~53: Ensure spelling is correct
Context: ...components - Better UX with appropriate snackbar notifications ## Features ### 1. HTTP...

(QB_NEW_EN_ORTHOGRAPHY_ERROR_IDS_1)

⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (1)
  • GitHub Check: Run Lint, Build and Deploy
🔇 Additional comments (2)
src/app/core/error-handler/README.md (1)

340-366: ✅ Test example now includes required Router mock.

The previous feedback about missing Router mock has been addressed. The test setup now correctly provides both MatSnackBar and Router dependencies (lines 342, 347–348), which matches the service's constructor requirements.

src/app/core/error-handler/error-handler.component.scss (1)

28-83: Use of !important is understandable but verify Material overrides work across versions.

The !important flags are used throughout to override Material Design defaults. While this is generally discouraged, it's often necessary when dealing with third-party component libraries. Ensure that targeting multiple selectors (.mat-mdc-snack-bar-label, .mdc-snackbar__label, .mat-simple-snackbar-action, .mat-mdc-button) is necessary for your Material Design version and component variants.

Consider documenting why these specific selectors are needed, or simplifying to the minimal set required if some are redundant.

@AnvayKharb
Copy link
Contributor Author

pl consider @gkbishnoi07

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants