Is your feature request related to a problem or challenge?
Yes. I've been digging into the services/ and utils/ directory recently, and I've noticed that error handling across the Eventra services (like aiRecommendationService and asyncValidators) is becoming quite fragmented.
Developers are manually updating individual files to replace console.error with logger.error (e.g., in PRs #8986, #8978). While this is a good immediate fix, it feels like playing "whack-a-mole." Every time a new API service is added, we have to remember to manually implement specific logging logic. It doesn't feel scalable as the project grows.
Describe the solution you'd like
I propose we implement a Global API Interceptor (using our current Axios/Fetch instance). Instead of individual services handling logging and error parsing, the interceptor should:
- Auto-capture: Automatically catch
4xx and 5xx status codes globally.
- Standardized Logging: Pipe these errors into our existing
logger utility with consistent metadata (Request URL, timestamp, and user session context).
- Error Normalization: Transform backend errors into a consistent
AppError format so the UI can display meaningful feedback (like toasts) rather than silent failures or raw console dumps.
Essentially, we move the "How to handle an error" logic from individual services into one central place.
Describe alternatives you've considered
I looked into continuing the current manual migration (replacing console.error one-by-one). While it works for small fixes, it’s not a long-term architectural solution. It doesn't solve the core issue of fragmented error structures returning from the backend.
Additional context
I’ve been tracking the recent PRs regarding SSR guards and logger migration in the repo. This feels like the logical next step to finish that clean-up.
I’ve done some preliminary digging into the services and I have a clear idea of how to wrap the existing network instances. If you think this aligns with the current architecture, I’d love to take a stab at it!
Is your feature request related to a problem or challenge?
Yes. I've been digging into the
services/andutils/directory recently, and I've noticed that error handling across the Eventra services (likeaiRecommendationServiceandasyncValidators) is becoming quite fragmented.Developers are manually updating individual files to replace
console.errorwithlogger.error(e.g., in PRs #8986, #8978). While this is a good immediate fix, it feels like playing "whack-a-mole." Every time a new API service is added, we have to remember to manually implement specific logging logic. It doesn't feel scalable as the project grows.Describe the solution you'd like
I propose we implement a Global API Interceptor (using our current Axios/Fetch instance). Instead of individual services handling logging and error parsing, the interceptor should:
4xxand5xxstatus codes globally.loggerutility with consistent metadata (Request URL, timestamp, and user session context).AppErrorformat so the UI can display meaningful feedback (like toasts) rather than silent failures or raw console dumps.Essentially, we move the "How to handle an error" logic from individual services into one central place.
Describe alternatives you've considered
I looked into continuing the current manual migration (replacing
console.errorone-by-one). While it works for small fixes, it’s not a long-term architectural solution. It doesn't solve the core issue of fragmented error structures returning from the backend.Additional context
I’ve been tracking the recent PRs regarding
SSRguards and logger migration in the repo. This feels like the logical next step to finish that clean-up.I’ve done some preliminary digging into the services and I have a clear idea of how to wrap the existing network instances. If you think this aligns with the current architecture, I’d love to take a stab at it!