Can you amend the Test Plan to include confirming that no warnings like this are presented: https://github.com/CommE2E/comm/blob/2901fdbf2fe11c8564c13fa3fe2513b8a05f5e29/native/chat/message.react.js#L118-L125

Looks good generally, but would be great if @atul could review the redux-persist migration since it's all client DB stuff and is based on a migration he previously wrote

Hmm it seems like we'll need to refactor this after getAvatarForUser gets converted to a hook (see my chat message)

This was easier than I realized!! Thanks for renaming everything. Will leave the diff on others' queues to get some other perspectives

It seems like this diff does some moving/refactoring and also introduces some new stuff, which makes it hard to review. More context: https://www.notion.so/commapp/Moving-code-around-bbb551c4350b4d5cb553c6751be44314?pvs=4

Fixes after in work in the subsequent diff

After running yarn arcpatch D7197, I noticed that the commit before this one is D7155. Does this work depend on D7155? If so, can you specify the stack on Phabricator?

Thanks for submitting!! I am clueless in Rust and this appears mostly Rust, so I will resign

Clarify that it's in the timezone of the keyserver

Requesting changes for inline comment, and for the discussion previously in D7076

Looks great! Please wait for Android build to complete successfully before landing

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?)

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

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

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.

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

Collection should be threadsafe

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

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!

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?

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