Re. Concern 1: Would this be okay? See below

Concern 1: It works without this, but I have a feeling that this value should be further exported to the callsites of useInputStateContainerSendMultimediaMessage().
I mean especially this.state.pendingUploads in web input-state-container. I haven't found any reason to do it on native though, but I might be missing something

I guess this can be done with Promise.all

Another "hack" - I'm taking advantage of keyserver not doing anything with the metadata, besides deducing MediaType basing on MIME type.

It would be better to somehow pass original upload data:

• On Web it could be easier because we store this.state.pendingUploads in input-state-container. The "alternative approach" could also be an option here
• On Native we don't store this data and we would have to update pendingUploads to store it, or add another variable

1. This dispatch is safe because I relied on where useInputStateContainerSendMultimediaMessage() is called.
2. It is always called after upload is finished (both native and web) so the old media ID already exists
3. It is always called inside "send multimedia message action" (inside dispatchActionPromise) so the messageID already exists too

2. Would it be okay to put it into Promise.all() I mentioned above?

I see formatting broke here.

1. This dispatch is safe because I relied on where useInputStateContainerSendMultimediaMessage() is called.
   • It is always called after upload is finished (both native and web) so the old media ID already exists
   • It is always called inside "send multimedia message action" (inside dispatchActionPromise) so the messageID already exists too

2. Would it be okay to put it into Promise.all() I mentioned above?

In my initial approach it used to be mutable, but if we decided we want to return this, I'll rather make it immutable, thanks

Yes, it doesn't really matter, I wanted to explain why I did this.
I proposed more "correct" alternatives, though they're much more involved

Yes

I suppose by this you mean the local ID already exists, and the server ID has not been determined yet since legacySendMultimediaMessage / sendMultimediaMessage haven't been called yet.

Yes

You're suggesting one dispatch per media, right? I'm not sure if there would be any benefits to this... dispatch isn't an async call, so it seems like migrateMessageMediaToKeyserver would still take pretty much the same time to complete.

I meant only code organization change: moving this into the previous loop (to-be-migrated into Promise.all) instead of doing another for loop.

Oh, I missed that it's already multiple dispatchs. Yeah, I think that's a good idea

I analyzed web code and basically, after sendMultimediaMessage is called, it only checks if the ID exists or not, it doesn't read its value anymore if it exists.
So it isn't necessary for this fix to fully work. However, it might be used in reports if they're sent late. To be correct, I decided to add it, it is pretty easy. I'll do it in next diff in the stack.

After getting confused twice 😅 I think this is correct.

1. At this point we're certain that this is a non-keyserver mediaID. Otherwise we continue
2. We require URI to be a blob URI, we fail if not.

It's a developer fault if we have ,media which is keyserver hosted (non-blob) and doesn't have keyserver ID.
The other way is legit - "blob-hosted media can have keyserver mediaID" - true for thin threads

Either way, I'll update this message to be less confusing