This replaces resultCount but it's the count of the number of successfully recorded shards not blobs.

Likewise this is recording the number of shards with leaked blobs rather than the number of leaked blobs. However, rather than just renaming the variable I think we should actually count the number of leaked blobs (i.e. += blobsToDelete.size() here).

Maybe apply the limit here on write (making the field an int) rather than each read?

A matter of taste, but consider extracting this section into its own method to clarify that we only get false on the branch that succeeded, all other paths lead to true (and maybe we should invert that so that true means "success").

        private boolean writeBlobsIfCapacity(IndexId indexId, int shardId, Collection<String> blobsToDelete) throws IOException {
            // There is a minimum of 1 byte available for writing
            if (this.truncatedShardDeleteResultsOutputStream.hasCapacity()) {
                new ShardSnapshotMetaDeleteResult(Objects.requireNonNull(indexId.getId()), shardId, blobsToDelete).writeTo(compressed);
                // We only want to read this shard delete result if we were able to write the entire object.
                // Otherwise, for partial writes, an EOFException will be thrown upon reading
                if (this.truncatedShardDeleteResultsOutputStream.hasCapacity()) {
                    resultsCount += 1;
                    return false;
                }
            }

            return true;
        }

Hmm it's not really within the implied contract of this class to be able to iterate its contents and then try and append more items. We've already closed the underlying compressed stream by this point. I think we should defer these assertions until the end.

This is trappy, it's going to generate a new randomIntBetween on each iteration so you don't get a uniform distribution of values. Better to count down from between(1,20) to zero, or else extract a variable for the upper bound.

WDYT about iterating until leakedBlobCount reaches some target value here, rather than doing the two separate loops?

👍 well spotted (in fact the stream grows anyway because we write the index ID, but that doesn't necessarily increase leakedBlobCount)