Incorporate requested feedback + test to make sure message pinning still works

FYI By mistake, two diffs had different order in the stack than in my branch on git - that's why I needed to fix parent/child revisions because arcanist didn't allow me to arc diff but this has no influence on the code itself

rebase before landing

rebase before landing

rebase before landing

rebase before landing

rebase before landing

reabse before landing

Please apply the requested change before landing!

Looks great, just minor nits! Great work on the synchronization, really for the distraction looking at threadsafe collections

Thanks @bartek, your explanation makes sense... I agree now that doing something on the Java side doesn't make any sense. I think we can move the discussion to D7120 for the JS side and safely land this diff as-is

Added a short description for the holder field

• Updated validateAndConvert to accept a single object argument
• Used serverCanHandleTypes to validate MIME type

Fix encryption_key -> encryptionKey

First of all, I'm sorry that my previous message sounds personal to you, I didn't mean it in any case.

After gathering the discussion above my statement on this is that:

1. I would follow @bartek approach since as he stated it is a common practice he encountered in open source projects.
2. If there is no acceptance to this approach I will make this method resolve not to two but to three values: false, true, null. The promise resolved to null will be interpreted in JS code that the request is already in progress and another promise will shortly resolve to some meaningful value we can react to (by querying for device token or setting it to null). It will probably be an early return in JS. Alternatively to resolving to ?boolean we can resolve to string constants such as GRANTED, DENIED and REQUEST_ALREADY_IN_PROGRESS.

Use Promise.all([...]) for checkThreadPermission and fetchMessageInfoByID to reduce the number of awaits (instead of await checkThreadPermission and await fetchMessageInfoByID)

Remove threadID from toggleMessagePinRequestInputValidator

Fetch the threadID via the messageID, remove threadID from ToggleMessagePinRequest and consolidate the two togglePinQuery queries into one concrete query (all addressing feedback)

sorry, requesting review again because i decided to just add the thread safety changes to this diff....

return early when we can

sorry addressing feedback now

make promises map thread-safe

Talked to @varun offline, plan is to handle thread safety in a later diff

i also missed jon's feedback from earlier so i'll address those comments now

Collection should be threadsafe

yeah fair i should just split this out into two diffs

fix

address last piece of feedback

Is this still meant to be a dummy / example diff that doesn't get landed?

Please make the requested changes before landing

No, I don't think so

remove unnecessary include

address feedback

I'm starting to wonder if it'd be better to revert my suggestion just to avoid all that fuss.

Awesome!! Thanks for taking the time to revise this a bunch, I know it was more complicated than initially expected

Thanks for explaining!

Really close!

rebase and land

Back to you

Ah but actually some of my other feedback hasn't been addressed yet

In retrospect, D7077 is the right place for this discussion – @inka, would you mind responding to my questions in this diff there?

don't include avatar if null (this should also now be landable as is)

In D7065#212101, @ashoat wrote:

Will this affect the height of the item? Have you made the necessary changes to the height determination code (textMessageItemHeight)?

I think we should include localMediaSelection, but not sure if a future diff adds that

Passing back to you with question about multiple files being uploaded to the same endpoint at once. I don't think we actually ever do this, so I'm wondering if we can simply throw an exception if we get multiple files in the same upload

Let's avoid setting avatar unless it exists, and only set it for a given UserInfo when that user calls the upstream methods to actually set their avatar. (At which point UPDATE_USER updates should help us avoid state inconsistencies.)

There shouldn't need to be any native release associated with this landing then, correct?

rebase and land