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 |https://hibernate.atlassian.net/browse/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
|
|
