[#4453] Fix ReplayToken.wasProcessedBeforeReset() for tokens without gap-walkback lowerBound semantics

[abuijze]

ReplayToken.wasProcessedBeforeReset() relied solely on lowerBound() + samePositionAs() to determine whether a replayed event had already been processed before the reset. This works correctly for GapAwareTrackingToken, whose lowerBound() walks back from gap positions, but breaks for token implementations whose lowerBound() computes a set-intersection — such as MongoTrackingToken.

When the reset token and the replayed event token are from completely different time periods, their event-ID sets are disjoint. The intersection is empty, and samePositionAs(empty, other) returns false, causing every replayed event to be misclassified as "new" instead of "replay". This has two observable effects:

1. @DisallowReplay handlers fire during a replay, and ReplayToken.isReplay() returns false.
2. advancedTo() falls into the "new event" branch and calls tokenAtReset.upperBound(newToken) for every replayed event, merging all event IDs into the stored token on every step. The token grows without bound until the backing store's size limit is exceeded.

The fix adds a covers() fallback: if resetLowerBound.covers(newTokenLowerBound) is true, the event was processed before the reset regardless of what lowerBound() returned. For GapAwareTrackingToken this fallback is dead code — whenever covers() would return true, the existing lowerBound() + samePositionAs() check already does. For set-intersection tokens it restores correct behaviour by using their time/position-based covers() implementation.

Two regression tests are added using a WindowedTrackingToken (an in-test stub whose lowerBound() returns the intersection of event-ID sets, mirroring MongoTrackingToken):

• one verifying that a replayed event from an earlier period is classified as a replay
• one verifying that tokenAtReset does not grow during replay

Also includes an unrelated bump of the TestContainers version to support running integration tests against more recent Docker installations.

Fixes #4453.

[jangalinski]

How (if so) will this affect the 5.1 branch?

[martijnvanderwoud]

Did a local test with this fix. Replays are working again for our MongoDB event store, thanks!

[smcvb]

Awesome job, looks good to me.

[smcvb]

Did a local test with this fix. Replays are working again for our MongoDB event store, thanks!

That feedback is extremely helpful, @martijnvanderwoud, thank you!! 🙏
If this fixes replays for you, can I assume we'd thus no longer require to tackle the Mongo Extension specific issue you created, @martijnvanderwoud?

[martijnvanderwoud]

Did a local test with this fix. Replays are working again for our MongoDB event store, thanks!

That feedback is extremely helpful, @martijnvanderwoud, thank you!! 🙏 If this fixes replays for you, can I assume we'd thus no longer require to tackle the Mongo Extension specific issue you created, @martijnvanderwoud?

@smcvb you are right, this reduces the impact of AxonFramework/extension-mongo#498 to almost zero. The unbounded growth now only occurs if the initial token at reset has an empty events collection, which is rare and easy to work around

Thanks guys for fixing this so quickly!

[smcvb]

Sure thing @martijnvanderwoud! And thank you for filing this with us!

[smcvb]

How (if so) will this affect the 5.1 branch?

It might, once we introduce tokens that are akin to the MongoTrackingToken in AF5, @jangalinski. That is not the case yet, though, so we're good for the 5.1 release next week

[sonarqubecloud]

❌ The last analysis has failed.

See analysis details on SonarQube Cloud