A Tracking Event Processor will only enter “retry mode” (mind you, this is not a replay) if the exception thrown from your Event Handling Component (the RegistryEventHandler in this case) is bubbled up towards the internals of the Tracking Event Processor.
In short, the framework provides two levels of error handling when it comes to Event Handling:
- The ListenerInvocationErrorHandler, which handles exceptions thrown by the Event Handling Components you write.
Defaults to the LoggingErrorHandler.
- The ErrorHandler, which handles exceptions thrown within the Event Processor.
Defaults to the PropagatingErrorHandler.
The reason you do not see the retry mechanism kicking in, is because the ListenerInvocationErrorHandler, which is defaulted to the LoggingErrorHandler, catches your RuntimeException and simply logs that it has occurred.
If you want your Event Handler to enter this retry mechanism, you should replace the ListenerInvocationErrorHandler for a PropagatingErrorHandler, which ensure the exception is thrown further up the chain. Mind you, this behaviour is not always desired.
If the Event Handling Component in question updates query models for example and you enforce it to retry instead of proceed with other models, you will start serving stale data to any part of the application which is interested in your Query Models.
By the way, the Reference Guide has the following on this topic, which would be a suggested read if you try to adjust this behaviour.
Lastly, the ReplayStatus is part of the replay functionality given to you through the Tracking Event Processor (which is described here).
Note that to utilize this functionality, you will have to call the
Concluding, you should be able to simply upgrade between minor and patch release, always.
Only between major versions can you expect breaking changes.
Thus, you should be able to safely update to 4.2.
Hope all this helps you out TibidibiDox!