Hijacking this ticket because we need to rethink the error handler to deal with improvements in Search 6:
Work plans now return a CompletableFuture. We could make them return a CompletableFuture<WorkPlanResult>, so that clients would have a detailed report of what happened while executing the work plan. The work plan result would more or less contain the same information as the ErrorContext from Search 5, except it would be an aggregation of results from multiple indexes. This result would be consumed by the AutomaticIndexingSynchronizationStrategy introduced in HSEARCH-3316.
The mass indexer now executes works through interfaces that return a CompletableFuture, so it is now able to detect errors on a per-entity basis. We could imagine a specialized interface to report these errors. Why not add a method to the MassIndexingMonitor, such as indexingFailed(Object entity, Throwable t)?
If we do the above, we’re down to a single use case for the ErrorHandler: the various IOExceptions we have in the Lucene backend when executing works. I believe some of them could be considered as work plan exceptions and thus added to the WorkPlanResult; for others, maybe we should see if they can be addressed with a separate solution?
For Search 5 we could think about several changes to the ErrorHandler API. A given is the improvement of the javadocs and online documentation (see HSEARCH-1353 ). Aside of that I suggest the following changes:
Have a single ErrorHandler#handle(ErrorContext) method with subclasses of ErrorContext (offer some sort of unwrap functionality for the user to deal with the different types)
If we not implement the single handle(ErrorContext) apporach I recommend at least to drop Exception in ErrorHandler#handleException. It would make the API more uniform
Regarding ErrorContext we should rename getFailingOperations and getOperationAtFault to make their intend clearer. A suggestion would be getNonAppliedWork() and getExceptionCausingWork() respective