Added new global error treatment (client-side)

[Machi3mfl]

This PR,
We need to centralize and normalize the way that we treat the errors thrown in execution time.
With this solution, we will centralize error management and use different artifacts that make easy the error treatment for the developer.
This is the first version of the error management for the client side using react and javascript/typescript patterns.

Solves partially the epic issue: #4145

For more details about error management checks de error-management docs:

• Main README.md
• Examples README.md

[Machi3mfl]

Error sources

• Wazuh API errors
• Elasticsearch Error
• Operational errors (development)
• Axios errors

Error management components

Error factory

The error factory is responsible to create different instances of error depending on the parameters received.

The error factory can receive:

• A string
• An error instance
• An error type: this param defines the error type returned

The errors returned are defined as the error type received.

• ElasticError
• WazuhApiError
• UIError
• etc

Error handler

The error handler is responsible to receive the errors (or strings) and define what type of error will be returned.
After identifying and classifying the parameters received the error factory returns a new error instance.
Always will return an error instance.

React patterns

The error handler can be implemented using react patterns:

• HOC (Higher order component)

• Hook

• Decorator (Coming soon)

[Machi3mfl]

How to use Error handler

Exists 3 ways to implement the error handler

• using javascript class errorHandler
• use a react hook called useErrorHanlder
• use a react HOC called withErrorHandler

These types of error handlers were created to give flexibility to the error management implementation.
All these implementations encapsulate the error handler class.

Error management architecture

graph TD;
 withErrorHandler-HOC-->ErrorHandler
 useErrorHandler-Hook-->ErrorHandler
 ErrorHandler-->ErrorFactory
 ErrorFactory-->WazuhApiError
 ErrorFactory-->WazuhReportingError
 ErrorFactory-->ElasticApiError
 ErrorFactory-->ElasticError
 ErrorFactory-->Etc

Loading

How to use Error Handler (class)

The recommended use of the Error Handler is in javascript methods (not react component).
This handler will receive an Error instance or error message and it will classify and categorize the error by its structure and create and return the corresponding Error instance.

Example

import ErrorHandler from 'error-handler';

// the handlerError is a static method
const newErrorCreated = ErrorHandler.handleError(errorResponse);
// the newErrorCreated var could be anyone error type defined in the graph above

How to use Error Handler (Hook)

The recommended use of the Error handler hook is when we have any method inside a component that makes an API call that can fail. In this case, will pass the async method like a javascript callback.

Example

import { useErrorHandler } from 'useErrorHandler'

const anyAsyncFunction = async () => {
      // this method could return an error or not
};

const [res, error] = useErrorHandler(anyAsyncFunction);

if(error){
   // treat the error
}
  
// the res var store the method response (API response)

Important
In this way, using the useErrorHandler hook we can omit the use of try-catch and do the code clear.

How to use Error Handler (HOC)

The recommended use of the Error Handler HOC is to catch all the errors produced in the component lifecycle.
This HOC will wrap the react component and will catch all the errors and treat them by the error handler class

Example

import { withErrorHandler } from 'withErrorHandler'

const Component = (props) => {
      useEffect(() => {
        // Component did mount
        functionWithError();
      }, []);
      return <div>Example Component</div>;
};

const ComponentWrapped = withErrorHandler(Component);

In this way, using the errorHandler HOC we can catch all the errors by the error handler class

How to use Error Handler (Decorator) coming soon

[Machi3mfl]

Errors Classes

The next diagram shows how is the relationship between the different types of errors created.

classDiagram

class iWazuhError {
    <<interface>>
    +Error error
    +string message
    +integer code    
    +handle()
}

iWazuhError <|-- WazuhError : implements
WazuhError <|-- WazuhApiError : extends
WazuhError <|-- WazuhReportingError : extends
WazuhError <|-- ElasticApiError : extends
WazuhError <|-- ElasticError : extends

Loading

[Machi3mfl]

Unit tests (Updated 17/02/23)

• Error factory
• Error handler
• Error handler HOC
• Error handler Hook

[Machi3mfl]

Tasks

• Implement ErrorHandler in plugins/wazuh-kibana-app/public/components/common/error-boundary

[Desvelao]

thought: Personally, I don't like the usage of the ErrorOrchestrator service. It looks overcomplicated to me.

[Desvelao]

praise: Good job adding some documentation about error management.

[Desvelao]

thought: I feel we should discuss how we want to manage the errors and the required implementation.

[Machi3mfl]

thought: Personally, I don't like the usage of the ErrorOrchestrator service. It looks overcomplicated to me.

I think is better to use the existing ErrorOrchestrator to avoid rewriting a new Error Logger. But, we can prepare the implementation to change the ErrorOrchestrator after with the lowest possible cost.

[Machi3mfl]

Next steps

• Add uses cases and document uses (In progress)
  • Added docs folders with use cases README and unit test for every use case
• See how to improve the error categorization - change the categorization by error code
  • Change the method of recognizing type errors for error URL requests inside error details inside code error received in an error message from the server-side plugin
• Add documentation about how the error is shown in the UI
• Get an issue related to wrong error handling and apply the new error management solution (In progress)
  • Issue to solve: Uncaught (in promise) TypeError in Integrity monitoring inventory #5210

[github-actions]

Code coverage (Jest)	%	values
Statements	9.45%	( 3500 / 37028 )
Branches	5%	( 1436 / 28712 )
Functions	8.11%	( 745 / 9175 )
Lines	9.53%	( 3380 / 35459 )