If all subscriptions would support Timebased subscription position, then we wouldn't need a cache (or just a very small cache). Instead, we would use the latest time-based subscription when we start the wrapped subscription. This should be possible in MongoDB by resuming from a BsonTimestamp in MongoCommons#applyStartPosition. I.e. if we parse the TimeBasedSubscriptionPosition into epoch ms. Note that this can be a bit dangerous outside the context of CatchupSubscirption because starting at a time-based position that is not in the oplog will yield an error (not enough oplog history, but is already handled in eg. SpringSubscriptionModels).
If all subscriptions would support Timebased subscription position, then we wouldn't need a cache (or just a very small cache). Instead, we would use the latest time-based subscription when we start the wrapped subscription. This should be possible in MongoDB by resuming from a BsonTimestamp in
MongoCommons#applyStartPosition. I.e. if we parse theTimeBasedSubscriptionPositioninto epoch ms. Note that this can be a bit dangerous outside the context of CatchupSubscirption because starting at a time-based position that is not in the oplog will yield an error (not enough oplog history, but is already handled in eg. SpringSubscriptionModels).