Accepting to unblock but the pattern of copy-paste is concerning

Please make sure @inka creates the task I requested before you land this

Looks like this is just a move diff so blindly accepting. Not familiar with that error myself, wondering what "initialization" means in this context (is it a circular dependency issue?)

address feedback

address feedback

rebase

update message list header to new desgin

No longer necessary with D7178

In D7132#212051, @ashoat wrote:

Mostly questions

remove stray ?

change order

new version of useGetAvatarForThread

Also throwing in @kuba, since he has been looking at chat-selectors.js recently too

rebase

address review

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