Reaccepting to unblock for now, in case you want to land and address later

Reaccepting to unblock for now, in case you want to land and fix later

It's at the bottom of this diff, I think you maybe didn't see it?

Please escape the . character in the RegExp before landing! Sorry I didn't notice this in my suggestion

One concern inline, please address before landing

Ah okay. Does that default always apply regardless of dev / prod mode? I guess that's convenient to be able to access from dev / prod mode of local keyserver. I wonder how to configure with Docker keyserver (I assume it won't be able to hit localhost, and will need some sort of config in the Docker Compose) but that's a topic for another day

In all of these cases we already have the threadInfo. Instead of requiring ThreadAvatar to fetch it again, should we just pass it in directly?

Looks good but see comments in D7260. I think we should move the userInfo fetch here and pass in ensAddress to useAvatarForUserID (which should get renamed to eg. useENSResolvedAvatar)

Actually after reading D7262 it took me way too long to understand what was going on here. I think we can improve readability

Seems right

Please address the nits before landing. Defer to you on whether the race condition I highlighted in set should be addressed or not

In D7261#215947, @varun wrote:

In D7261#215926, @ashoat wrote:

Without identityAuthToken I'm getting this error from rust-node-addon:

thread 'tokio-runtime-worker' panicked at 'called `Result::unwrap()` on an `Err` value: Error("key must be a string", line: 1, column: 2)', src/identity_client/mod.rs:58:47

hmmm can you echo $COMM_JSONCONFIG_secrets_identity_service_config? it looks like the env var is currently set to invalid JSON

Without identityAuthToken I'm getting this error from rust-node-addon:

Thanks for explaining!

EDIT ignore this comment - I was confused. It seems that no additional config is necessary to test in dev mode.

It would be good to have unit tests for segmentAndStem, but I don't want to block you from landing this. Can you create a follow-up task for that before landing?

Thanks for separating this out!

Thanks for the detailed explanation and code example, @bartek – it looks like your approach is correct here

I just had a 1:1 with @michal and asked for detailed instructions for how to generate this diff:

Thanks for fixing this!

Have you tried the code snippet I suggested in my first review on Tuesday? Does it work or no?

Don't have much more to say

"Add useMemo" isn't a good follow-up task, please respond to the diff comments here directly

What happens if you deploy a debug build to an iOS device that previously had a release build? It would be able to keep using the previously determined encryptionKey, right? (And vice versa, going from debug to release?)

I'm also wondering if we should remove the punctuation from inside of words. Maybe only strip the punctuation at the beginning and at the end? Since it makes sense to leave o'clock and 100,000 and such.

Just a question:

Just a question. Will leave it on others' queue in case they have review comments

Sorry for requesting changes again, but I have a couple of questions. If you don't think any changes are necessary, please feel free to respond to my questions and re-request review!

s/down/done corrects a typo of "down" with "done". It's using SED syntax for find-replace

In D7212#214878, @atul wrote:

Might be missing something, but should we add a migration to native that adds commServicesAccessToken field to Redux if it doesn't already exist?

Requesting changes to either "rewrite with inspiration" or to move copy-pasted code to a third-party folder with the license

Minor comments

1. Can you separate the codegenned parts and your modifications into separate diffs?
2. For the codegenned diffs, can you list the exact commands you ran to generate the code?

Intl.Segmenter seems like the best bet! We can figure out the Flow types... worst case we might need to do something like const OurIntl: OurIntlType = (Intl: any); or something.

Perfect!

Accepting with a question. Don't think we need to throw the last result away

Just nits, but requesting changes because some of them are non-obvious and I want to confirm it's implemented right before you land :)