It was done this way earlier in the blobServiceUpload above in this file. We have the following flow:

1. Create a holder and see if data_exists
2. If data doesn't exist, perform blob upload
3. Only for successful blob uploads let keyserver know by calling the upload_media_metadata endpoint. The endpoint expects a holder to already exist

It was designed this way from the beginning to be more error-proof:
If 1 or 2 fails, the keyserver won't receive any notice, and Blob Service will do the cleanup if needed, and we can retry. If the keyserver did the holder assignment, we could end up with keyserver DB entries without blobs successfully uploaded, and recovering from this isn't that easy.

Here in this function, we do only 1. and 3.

I copied the comment from blobServiceUpload above and forgot to update it.

I'm more confused now unfortunately...

Questions:

1. It seems like in order to understand your response, I need to understand what happens before mediaMetadataUpload is called. Can you share that context?
2. It sounds like by the time mediaMetadataUpload is called, the blob has already been uploaded? Is that why we're skipping step 2 in this flow?
3. What's the purpose of setting a new holder here if the blob has already been uploaded?
4. What do we do with the original holder? Do we clear it?
5. Why isn't the keyserver owning the holder?

1. mediaMetadataUpload is called only for already-uploaded thick thread media, which we're migrating into thin thread media.
2. Yes, it is. It already has a holder (1 and 2 done), but it is a local holder from holder store, and we need another one for keyserver.
3. I guess I answered in 2.
4. we discussed it on Linear and agreed to clear it. I'm going to do it in the next diff (where we can take advantage of batching this operation)
5. This new holder is going to be owned by the keyserver and forgotten locally

The first name looks reasonable!

The blobHash variable name is taken in L358 for processed input.