This is related to
SOLR-7332 ... I used to set the highest value on the version buckets based on a lookup to the index whenever a firstSearcher event fired, but that led to reentrant lock issues (see SOLR-7587), so I moved that version seeding code into the SolrCore constructor.
While working on
SOLR-4506, I just realized that if a core has to pull index files from the leader to recover, then the version bucket doesn't get updated once the new index files are pulled over. In other words, the code seeds the version buckets during core init, but if the underlying index changes due to being too far out-of-date, then the version buckets are never updated once the new index is in place. The risk is that if bucket versions are seeded with a value that is too low, then it can lead to correctness issues with versioned updates.