Hi Sara, Steven,
I have had plenty of airport waiting time last week, and gave this some thought. At first (when discussing this with Steven) I was looking in the direction of somehow connecting two processors. However, I think the solution is much simpler than that.
At the moment, triggering a replay is a “manual” job. You need to remove the token and clear the projections. We have been talking about adding an explicit API to the TrackingEventProcessor to make this easier. Just like “start” and “shutdown”, there should also be a “reset” method.
The initial idea was to either allow handlers to reset, or prevent resetting the processor, which would, for example, be the case with Sagas or any event handler that causes a side-effect (email, external systems, etc). Any solution in that direction quickly resulted in a type of complexity that made it almost unbearable.
The approach that we’re currently looking into is to support “partial reset”. When resetting a Processor, it would invoke all “pre-reset” handlers and check if all handlers support this reset. If one or more handlers don’t support reset, a special token is used. If all handlers do support a reset, the token is cleared as part of the reset. If no handlers support resetting, the reset should be rejected.
This special token, a PartialResetToken would contain the original token as well as the token that is being processes at the moment. So if at a moment when the token is Tx, the processor is reset, a PartialResetToken (Tx, null) would be created. The null represents the lack of a token for the “general handler population”, causing it to track from the beginning of the stream. This token is then updated until it is equal to Tx (or when one token “covers” the other). In that case, the reset is considered complete and the processor is continuing work where it left off. From that moment on, the handlers that didn’t support reset are also invoked.
While this process might seem complicated, the main advantage is that it doesn’t affect any other components than the processor itself. The processor will need to be able to detect whether it is using a PartialResetToken and extract the two subtokens from it. That’s easy. Somewhat harder, but also already solved as part of another story in Axon 3.1 is being able to tell the relative difference between two given tokens,allowing the TrackingProcessor to recognize when it has finished a replay.
Hope this makes some sense.