-
Notifications
You must be signed in to change notification settings - Fork 791
Web 429 implement centralized error handler service for user friendly api error messaging #2810
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: dev
Are you sure you want to change the base?
Conversation
|
Note
|
| 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
Estimated code review effort
🎯 3 (Moderate) | ⏱️ ~25 minutes
- Verify HTTP status → message mappings and server payload parsing for sensitive data exposure.
- Confirm
handleErrorpreserves 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
@usepath insrc/main.scssresolves 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.
Comment @coderabbitai help to get the list of available commands and usage tips.
There was a problem hiding this 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: ClarifyhandleError’s primary usage pattern withcatchError.The examples currently mix
catchError((error) => this.errorHandler.handleError(error))with directsubscribe(..., error => this.errorHandler.handleError(error)). SincehandleErrorboth shows a snackbar and returns athrowErrorobservable, it may help to explicitly recommend thecatchErrorpattern as the default and note that, when using it from a plainsubscribeerror 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 beyondErrorEventto coverstatus === 0.Currently connection issues are only recognized when
error.error instanceof ErrorEvent. Angular can also surface network/offline failures asHttpErrorResponsewithstatus === 0and a non‑ErrorEventpayload, which would then fall through to the generic “Error” case. To better match the documented “Network Error → Connection Error” behavior, consider treatingstatus === 0as 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
📒 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.tssrc/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.
showSuccessandshowInfouse clear defaults, appropriate durations/positions, and thepanelClassvalues line up with both the README andmain.scss. Centralizing these helpers should significantly reduce duplicated snackbar config in components.
There was a problem hiding this 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
📒 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.tssrc/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
ErrorMessageinterface, and proper dependency injection ofMatSnackBar. The singleton pattern viaprovidedIn: '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 || fallbackensures users see meaningful error details when available.
157-178: LGTM! Well-designed notification methods.The
showSuccessandshowInfomethods 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()andcatchError(), and the import path@core/error-handler/error-handler.servicefollows 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].defaultUserMessage→defaultUserMessage→ fallback). The migration guide clearly demonstrates the improvement over previous error handling, and the testing example provides a solid foundation for unit tests.
There was a problem hiding this 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
contextparameter is thoughtfully used for 404 errors to provide specific resource context.One optional enhancement: Consider utilizing
contextfor 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
📒 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
ErrorMessageinterface is clean and properly exported for potential consumer use. The optionalactionfield provides flexibility for different error scenarios.
40-43: Constructor properly implements dependency injection.The service correctly injects
MatSnackBarfor UI notifications andRouterfor 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 andthrowError(() => 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.
|
@gkbishnoi07 Please review this |
fd7a967 to
346ccf5
Compare
|
@alberto-art3ch @steinwinde please review ..! |
alberto-art3ch
left a comment
There was a problem hiding this 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
There was a problem hiding this 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()andshowInfo()method signatures could explicitly document their return type (void) for completeness, matching the explicit return type documentation forhandleError().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
📒 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.scsssrc/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.
|
@alberto-art3ch Thanks, Alberto! Quick update: Error handling: Snackbar styles: |
|
please squash your commit @AnvayKharb |
dad9a89 to
1b778b8
Compare
|
heyy @gkbishnoi07 I've just squashed my commits |
There was a problem hiding this 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 becauseMatSnackBarcompletes 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
📒 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.tssrc/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
ErrorMessageinterface 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 thehandleErrormethod follows the proper RxJS pattern for use withcatchErroroperators. The use ofthrowError(() => 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.
…-api-error-messaging
1b778b8 to
8c59c27
Compare
There was a problem hiding this 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
📒 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.scsssrc/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.
|
pl consider @gkbishnoi07 |
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
Documentation
Style
✏️ Tip: You can customize this high-level summary in your review settings.