note that this PR does not include the conflict resolution logic when there is a CreateIndex transaction vs a Rewrite transaction that both tries to create a new frag reuse index. That is handled in the next PR.

There is a load_indices_by_name method. Maybe we should convert it to load_index_by_name and then you can use it here?

+1 I originally used that but ended up doing this because that one returns a list and I still need to check empty or select the first one. I think it is definitely worth adding a load_index_by_name which can remove a lot of similar code like this even for other indices.

I wonder if we should even start considering name to be unique. We have APIs like drop_index which take the index name as a parameter and sort of imply that a unique index name is already the case.

The APIs are a bit inconsistent at this point, for example drop_index will drop all the indices sharing the same name, so technically drop_indices(&mut self, name: &str) is a more correct name:

let transaction = Transaction::new(
            self.manifest.version,
            Operation::CreateIndex {
                new_indices: vec![],
                removed_indices: indices.clone(),
            },
            /*blobs_op= */ None,
            None,
        );

But in prewarm_index, it assumes there is only 1 index per name and only warms the first index of that name:

let index = self
            .open_generic_index(name, &indices[0].uuid.to_string(), &NoOpMetricsCollector)
            .await?;
        index.prewarm().await?;

Maybe we need to just re-examine all of them to make them at least consistent. But my understanding is that there could be delta indices that share the same name but are different UUIDs, so we cannot really enforce unique index name?

Should we keep track of whether any versions were cleaned up? If nothing is cleaned up we could probably return early instead of proceeding with a transaction?

We should maybe suggest a retrain here so users have a way to remove the warning.

I wonder if this should be "return error" or just "log warning and skip"? Hopefully it just never happens, but if it did happen what would be the cleanup? Should the user just remove the frag reuse index at that point?

yeah if this ever happens that means the reuse version is corrupted. I kept the logic here, but made the cleanup function remove the version when this error is triggered.