See comment here... I'm wondering if we can just implement a final solution now instead of more testing. It feels like we maybe fully understand what's causing the issue now, no?

I don't think you should be swallowing the exception. If you disagree, can you please explain and then re-request review?

Continued issues with async / await... at this point I feel like a broken record saying "I feel like a broken record"

Glad we caught this before the feature shipped!! Testing within the Comm community was a great test plan for this one

Talked to @varun offline. We have similar code in keyserver/src/search/users.js and keyserver/src/creators/account-creator.js... would be good to dedup all of it. searchForUser is probably good for what we need in all three cases

1. We need to make sure that the identity service has the codeVersion of the client. When we launch the device list work, the identity service will need to be able to identify whether a given client is able to support the "new" workflow and function as a primary device. This is just one example of many... it's critical that Comm services are aware of the client version
   • @jon mentioned that this value won't be up-to-date, but that's better than nothing. If in the future we need a more up-to-date value, we can have newer clients call some other identity service RPC when their version changes
2. As discussed offline, let's break this down into 'ios' | 'android' | 'web' | 'macos' | 'windows'

Accepting for a staff-only release

One of the new FAQ items we're putting up on the landing page is "What happens if my keyserver is lost?"

Okay, fair enough – I agree it's not worth that much effort. Especially if all three of you had trouble

Makes sense to me, but I'd like @tomek to give a final approval since he suggested the multi-update query

Not sure I need to be added here... maybe somebody else can give it a first stab, and add me if they feel it's necessary? The last several of @marcin's notifs diffs have been reviewed by @tomek / @bartek and I think things have generally gone well (outside of a few strange issues, but we haven't really identified any code / code review problems as causing those)

Please add me back before landing this, once you're sure it's 100%

I haven't reviewed the latest pass. Please add me before landing. By the time you add me, I should be able to simply accept the diff. See my comment here for details.

Please add me as a blocking reviewer before landing, once you're both sure I'll be able to simply accept the diff without needing to request any changes

I simply can't be the first line reviewer for @jon's docs diffs anymore – this isn't a good use of my time, and frankly it's deeply frustrating for me. I feel like I'm saying the same things over and over.

Thanks for attaching! In addition to my above comments, I can leave some guidance on the image grid. The image grid is treated somewhat differently... we basically want to fit the image into the space available in the grid. For small images we can "zoom" them in, and for larger images we can "zoom" them out. Let me know if you have any questions about this, or my previous comment.

I can't see your attachments.

Thanks!

How about .github/workflows/windows_ci.yml? Can you update that one too before landing?

thread-permission-updaters.js is one of the most complex parts of the keyserver codebase. Some quick notes:

I'd really like to see a solution that doesn't use *, any, or $FlowFixMe. I'm not sure, but I suspect that this is possible here. I've created a start for you with D8685 and D8686. Can you please rebase this diff on top of that stack, and try to find a way forward without using *?

I don't have much spare time, but I took a look at this for you

Thanks for explaining! This looks good to me, but I'd like one of the other reviewers to review it as well, since I don't know how to read .tf files yet

I'm probably missing the method you're talking about to re-create the crash, and if so it makes sense that we should definitely avoid that. If that is the case, I can bring back the original method of pulling from Redux if it exists

Accepting, but please address inline comment before landing

Thanks for testing those cases!

Can you clarify how the secret is stored / accessed? Eg. does the human running the script enter their AWS credentials somewhere (or perhaps the AWS credentials of the Terraform account, or the AWS credentials of an IAM user on the Terraform account) to access the secret? If so, where / how are those credentials entered?

I have a lot of small comments below. None of them are substantial, so I'll accept here, but please make sure to address comments before landing!

Heads-up, it looks like you've not specified any reviewers

Thank you!!

Agree with @michal... wondering, what if we use a default type param here? Then we could just use BaseAppState<>.