Error in Error Handler!!!

In Mule we have many components for different processing scenarios and are Java classes implementing specific functionalities. The exceptions and errors occurring in these classes may break the Mule flow. Error handlers are provided in Mule flows to make sure these exceptions are handled in a controlled way.

In Mule 4, error handling is not limited to the framework of Java exception,but it has introduced a formal Error concept that is easier to use even though Java Throwable errors and exceptions are still available. It is possible for each component to declare the type of error it can throw, and handle potential errors at design time.

Mule 4 has redesigned error handling by introducing the error-handler component, which can contain any number of internal handlers and can route an error to the first one matching it. Two types of error handler are provided in Mule 4

  • On-error-continue handler executes and uses the result of the execution as the result of its owner (as though the owner completed the execution successfully). Any transactions at this point are committed, as well.
  • On-error-propagate handler rolls back any transactions, executes, and uses that result to re-throw the existing error, meaning its owner is considered to be “failing.”


The Un- Explored Scenarios:

Current runtime is in Mule 4.2.2 and the Mule flow is designed to read a CSV file and insert those data into the Database. An Exception handler is provided for handling the exceptions occurring at run time and sending an error response. There is a need to migrate the same to Mule 4.3.0 with the latest updated components available for Mule 4.3.0.

The flow consists of a FTPS reader for reading the CSV file and a Database component for inserting the data into DB. For handling the error occurring in DB we have added the Database component in an try catch block and used a flow reference to route the error into the error handler.

Flow and Error Handler design:

 

The code got deployed to Mule 4.2.2, without any issues. However when it was migrated to Mule 4.3.0 deployment failed giving an error which is not specifying the cause of error.

Error In Detail:

  
++++++++++++++++++++++++++++++++++++++++++++++++++++++
+ Failed to deploy artifact 'csv-to-database', see artifact's log for     +
+ details                                                                      +
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
ERROR 2021-04-10 23:53:08,773 [WrapperListener_start_runner] org.mule.runtime.module.deployment.internal.DefaultArchiveDeployer: Failed to deploy artifact [csv-to-database]
org.mule.runtime.deployment.model.api.DeploymentException: Failed to deploy artifact [csv-to-database]
Caused by: org.mule.runtime.api.exception.MuleRuntimeException: org.mule.runtime.deployment.model.api.DeploymentStartException: Error starting application 'csv-to-database'
Caused by: org.mule.runtime.deployment.model.api.DeploymentStartException: Error starting application 'csv-to-database'
Caused by: org.mule.runtime.api.lifecycle.LifecycleException: No subscriptions active for processor.
Caused by: org.mule.runtime.api.exception.DefaultMuleException: No subscriptions active for processor.
Caused by: org.mule.runtime.api.exception.MuleRuntimeException: No subscriptions active for processor.
Caused by: java.lang.NullPointerException
	at java.util.concurrent.ConcurrentHashMap.putVal(ConcurrentHashMap.java:1011) ~[?:1.8.0_265]
	at java.util.concurrent.ConcurrentHashMap.put(ConcurrentHashMap.java:1006) ~[?:1.8.0_265]
	at java.util.Collections$SetFromMap.add(Collections.java:5515) ~[?:1.8.0_265]
	at org.mule.runtime.core.privileged.exception.TemplateOnErrorHandler$OnErrorHandlerFluxObjectFactory.apply(TemplateOnErrorHandler.java:159) ~[mule-core-4.3.0-20201013.jar:4.3.0-20201013]
	at org.mule.runtime.core.privileged.exception.TemplateOnErrorHandler$OnErrorHandlerFluxObjectFactory.apply(TemplateOnErrorHandler.java:120) ~[mule-core-4.3.0-20201013.jar:4.3.0-20201013]
	at org.mule.runtime.core.privileged.exception.TemplateOnErrorHandler.router(TemplateOnErrorHandler.java:183) ~[mule-core-4.3.0-20201013.jar:4.3.0-20201013]
	at org.mule.runtime.core.internal.exception.ErrorHandler.router(ErrorHandler.java:108) ~[mule-core-4.3.0-20201013.jar:4.3.0-20201013]

Uncovering root cause and the solution:

The error: “No subscriptions active for processor “, is not giving insights to the root cause. The interesting part is that the issue will not get caught in Debug Mode as the application will get deployed properly.

After a series of introspections the root cause was pointed to the below reasons

  1. We created one Global Error Handler and not configured it in global properties
  2. When running on Mule 4.2.2 the error handler uses flow reference whereas in Mule 4.3.0 flow reference is not honoured and has to configure it in global configurations

Proposed solution to be kept in mind while migrating is detailed below

  1. Create Global error handler and configure it in global configuration
  2. Remove flow reference for calling the error handler
  3. Specify a type of error in Try Catch block and use Raise error component for throwing the error into Global Error handler