Improving error/exception handling

[mlqn]

Asynchronous errors

We currently lack a consistent mechanism to catch expected and unexpected (e.g. a network problem/502/503/504 errors, 404 errors) asynchronous errors, resulting in the absence of error messages for the user.

I suggest implementing a global error handling system that catches and logs all errors coming from our API calls, displaying a specific message when possible, and a generic message otherwise. This generic message would say that an error has occurred, that we are aware of it, and that we are working on it. This approach could potentially reduce the number of messages we receive from users via the studio channels.

Since we are using Axios as our HTTP client, handling these errors can easily be done by using Axios interceptors. We could use these interceptors to perform other actions, such as logging out a user when we receive a 401 unauthorized exception, and informing them that their session has ended (#10718)

I suggest displaying these error messages as toast notifications using react-toastify. We could use it to display success messages and synchronous errors too. Using notifications have multiple benefits :

• they are always visible, even if you are at the bottom of the page
• they do not break the design by pushing blocks around
• they can automatically disappear after a set amount of time
• they're both non-blocking and non-intrusive, allowing users to continue their work interrupting them

To display specific messages, we could return an errorCode or a messageKey from the API, and then use this code/key to find the associated user-friendly message within our text resources in the right language.
This approach would help us to display distinct messages for the same HTTP error code (e.g. 400 error could be a missing parameter or a bad format, etc) and would also facilitate the implementation of specific actions on the client side. We probably cannot directly display the error message from the API, as it may contain technical information and is currently not translated into the local language.

In addition, we could still display some specific messages as we do today by using the onError callback of react-query and by checking the HTTP status code (e.g. 400 Bad Request) on the client side.

Synchronous / Rendering errors

To handle rendering errors, we could just use error boundaries as mentioned in this issue : #7265

Tasks

Beta Give feedback

1. Create generic error handling mechanism #10735
   +0
   
2. Cleanup useMutation messages #10827
   +0
   
3. Cleanup error message components #11360
   kind/chore status/triage text/content ux +4
   
4. Handle error codes returned by the API #10846
   +0
   

   
5. Ensure the user is logged out when the session is invalid or expired #10942
   kind/bug +1
   
6. Use error boundry to show an error message when studio crashes #7265
   kind/feature-request quality/code +2
7. Create contact page #10898
   2 of 3
   area/contact kind/user-story ux +3
   
8. Add more ErrorBoundaries at different levels #11754
   kind/feature-request status/ready-for-specification +2
   
9. Improve ErrorBoundary #11318
   0 of 2
   kind/chore status/triage +2
10. Prevent passing custom QueryClient instance to ServicesContext #10913
    kind/chore quality/code quality/testing status/triage +4
    
11. Replace default toast component with Alert component #10826
    area/designsystem area/notification good first issue kind/chore status/wontfix +5
12. Show success / info messages using toast component
13. Remove toast for error messages in specific places #11885
    +0
    

[mlqn]

Here are some examples where an error was returned by the API and the user was not informed about it:

• Syncing issues between Gitea and Studio #10731
• Show an error message when data are not auto saved #10630
• In Data Model / Edit, "List of valid values," we need to generate unique IDs for the values because they receive a 500 error in the console, which doesn't show in the UI. #10624
• Improve error messages in Datamodel #10622
• User should be given feedback/error message if deleting a text fails #10420
• When deploying an ap with an invalid json text resource we get 502 #10657