We're updating the issue view to help you get more done. 

Improve design of ErrorHandler

Description

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?

Original ticket:

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

Environment

None

Status

Assignee

Unassigned

Reporter

Hardy Ferentschik

Labels

None

Suitable for new contributors

None

Pull Request

None

Feedback Requested

None

Components

Fix versions

Affects versions

4.4.0.Alpha1

Priority

Major