Default `ReplayToken` leads to events not being handled when used with Disallow Replay API about axonframework

[nils-christian]

Hi @smcvb,

Thank you for updating the release notes accordingly. I am still not sure that I agree with the decision, but I understand your arguments and I am glad to see that it is documented.

About your question: This might be a nice feature indeed, but to be honest - we probably wouldn't use it. In our case we already have a (spring bean managed) class that allows to configure event processors based on our own conventions. Additionally we already changed the default event processing configuration, so the fix with the initial tracking token was rather easy for us.

Thank you and Best regards

Nils

[651juan]

Hi @smcvb ,

Thanks for the explanation.

We only had this issue on one of our new services where we did not have the EventProcessingConfigurer defined. We've added the EventProcessingConfigurer and this is no longer a problem for us.

Thanks!

[nils-christian]

Hi,

After talking with a colleague about this topic, we think that this is even more of a breaking change than I originally thought. Up to 4.8 it was possible to add a new tracking event processor to an application which would then handle all previous events. This is (in our opinion) a common use case. Starting with 4.9 this no longer works (at least not with event handlers marked with DisallowReplay), as the initial run is marked as "replay". This is very unexpected and should at least be documented as breaking change in the migration notes.

Best regards

Nils

[651juan]

We have experienced the same issue. Was quite surprised, I think this should be communicated as a breaking change.

[smcvb]

Thanks for your concerns, @nils-christian and @651juan. And my apologies for the late reply. My days have been rather stretched thin with the other tasks at hand.

I think the crux lies in the added logic to the Event Handler or Event Handling Component with the @DisallowReplay annotation, correct?
Whenever a new Event Handling Component that's backed by a StreamingEventProcessor is introduced without use of the @DisallowReplay annotation or ReplayStatus#REPLAY enumeration, the behavior would stay the same.
The Event Processor would receive all events and look for applicable handlers, just as it did for 4.8.

The switch towards a default ReplayToken would cover the scenario that the Event Handler that performs side-effects is not invoked based on past events.
As stated in #2778, we've had numerous scenarios since the introduction of the TrackingToken in Axon Framework 3 where people actually expected a new Event Processor to enter the replay mode; because it is handling old events.

In your defense, @nils-christian and @651juan, I would mark both of you as seasoned Axon Framework users.
I fully comprehend this hard shift comes as a surprise in that regard.

As such, I wholeheartedly agree we should've communicated this as a breaking change.
We were under the impression we wouldn't hit anybody against their shins with this adjustment.
Hence, I want to apologize for this to both of you, and any other potential readers of this issue.

However, given the Framework team's desire to simplify things for the majority, we are hard-pressed to revert this change as we still believe it benefits new(er) users greatly.
Nonetheless, as both of you are entirely right that we lacked in notifying existing users of this shift, I have just updated the GitHub Release Notes and Reference Guide's Release Notes accordingly with this breaking change.

Furthermore, I would like to take this opportunity to discuss the possibility of switching the behavior more easily for a given Streaming Event Processor, or perhaps the complete Axon Framework application.
For example, an EventProcessingConfigurer (and thus Spring Boot property) configuration option to set the overall default TrackingToken for new Streaming Event Processors.
Would such a solution provide a nicer way forward than the suggested workaround?

[smcvb]

Thanks for the replies, @nils-christian and @651juan.
Interaction like this is a plain necessity to make an Open Source project viable.

I am still not sure that I agree with the decision, but I understand your arguments and I am glad to see that it is documented.

@nils-christian, we'll take your comment to heart for future occurrences. 👍

As I notice that both of you are okay with the documentation and follow our reasoning, I will be closing this issue as resolved.
If you guys, or anybody else, thinks my earlier suggestion would be beneficial as a solution, we'll gladly reopen this issue and provide a PR.