Error Handler Middleware
██████╗ ██╗████████╗██████╗ █████╗ ██╗ ██╗
██╔════╝ ██║╚══██╔══╝██╔══██╗██╔══██╗╚██╗ ██╔╝
██║ ███╗██║ ██║ ██████╔╝███████║ ╚████╔╝
██║ ██║██║ ██║ ██╔══██╗██╔══██║ ╚██╔╝
╚██████╔╝██║ ██║ ██║ ██║██║ ██║ ██║
╚═════╝ ╚═╝ ╚═╝ ╚═╝ ╚═╝╚═╝ ╚═╝ ╚═╝
Official Wiki of the GitRay Repository!
Back to Home
Overview of Error Handler Middleware:
- Central error handling middleware for the Express.js backend application
- Catches and processes all unhandled errors in the middleware chain
- Provides structured error responses with appropriate HTTP status codes
- Integrates with logging and metrics systems for error tracking
- Differentiates between known GitrayError instances and unknown errors
What does this feature/component exactly do:
- Logs detailed error information including stack traces, request paths, method, and user types using the logger service
- Records detailed error metrics with severity classification (warning for GitrayError, critical for unknown errors)
- Tracks user impact assessment (degraded for known errors, blocking for unknown errors)
- Updates service health scores for the 'api' service with error rate tracking
- Records failed feature usage based on the request path's second segment
- Determines user type from request headers (api, ui, admin, unknown) for analytics
- Returns structured JSON error responses with error message and code for GitrayError instances
- Falls back to HTTP 500 with generic message for unknown/unexpected errors
- Suggests recovery actions through the metrics system (defaulting to 'retry')
What is the trigger of this feature/component:
- Any unhandled error thrown by previous middleware or route handlers
- Explicitly thrown GitrayError instances with specific error codes
- Unexpected application errors or exceptions
- Database connection failures, validation errors, or service unavailability
What happens with the GUI:
- Frontend receives structured JSON error responses
- Error messages are displayed to users in appropriate UI components
- HTTP status codes help determine the severity and type of error
- Known errors show specific user-friendly messages
What happens in the background/Backend:
- Error details are logged with comprehensive context including error message, stack trace, request path, HTTP method, and determined user type
- Detailed error metrics are recorded with classification:
- Severity: 'warning' for GitrayError instances, 'critical' for unknown errors
- User Impact: 'degraded' for known errors, 'blocking' for unknown errors
- Recovery Action: 'retry' is suggested for all errors
- Service health scores are updated for the 'api' service with error rate incremented and immediate response time (0ms)
- Failed feature usage is tracked by extracting the feature name from the request path (second URL segment)
- User type is determined from request headers using getUserType() function to categorize users as 'api', 'ui', 'admin', or 'unknown'
- All metrics integration enables comprehensive monitoring, alerting, and analytics for error patterns and system reliability
Error Handler Middleware:
- File name:
errorHandler.ts - Project path:
apps/backend/src/middlewares/errorHandler.ts
Unit-Test:
- File name:
errorHandler.unit.test.ts - Project path:
apps/backend/__tests__/unit/middlewares/errorHandler.unit.test.ts - Note: Test coverage needs enhancement to include metrics service mocking and testing of all error handler functionality
- File name and project path:
apps/backend/src/services/logger.ts- Logging service used for error logging - File name and project path:
packages/shared-types/src/index.ts- GitrayError types and HTTP status constants - File name and project path:
apps/backend/src/services/metrics.ts- Metrics recording and service health tracking - File name and project path:
apps/backend/src/index.ts- Main application file where middleware is registered
