cloneCollectionAsCapped creates a new capped collection and puts the data from an existing collection into it. It generates multiple oplog entries: first an oplog entry to create the new capped collection, then individual oplog entries to insert documents from the existing collection into the new capped collection.

convertToCapped uses cloneCollectionAsCapped's machinery to create a new capped collection and put data from an existing collection into it, then rename the new capped collection over the existing collection. So, it also generates the same oplog entries as cloneCollectionAsCapped, plus an oplog entry for the rename.

Currently, it's possible for a tenant migration to start blocking after cloneCollectionAsCapped or convertToCapped have written only some of their oplog entries. The operations will fail but leave the capped collection around as garbage on the donor, and the recipient will have the capped collection as garbage as well.

I think it's also possible for this garbage to be created if a stepdown happens during cloneCollectionAsCapped or convertToCapped today.