rebase

make authoritative id variable a config json object

Updated test plan after some more testing.

fix logic, still need to do more testing

rebase

configure user credentials as json object variable instead of individual string variables

Lot of things that need to be fixed up here.

rebase after addressing feedback in previous diffs in stack, still need to fix this diff up

move changes to stripMemberPermissionsFromRawThreadInfo into this diff

update diff with ESLint and validator unit test resolved.

update to address ESLint and failing validator test. flow issue(s) still expected.

rebase

still would like to see the ESLint fix moved to the diff where the issue is introduced.

fix ESLint issue

rebase after landing validator fix

rebase after landing validator fix.

Ran yarn eslint:all, yarn flow:all, and yarn jest:all locally and confirmed that they all passed without issue. Will wait for ESLint & Flow & Jest workflow to pass before landing.

cherry-pick and land, validator test should pass now

cherry-pick and land

Can also cherry-pick and land this to simplify stack before rebasing and addressing all feedback.

Ah okay, sorry I missed that

In D12594#361908, @ashoat wrote:

Hmm looks like a bunch of Flow errors

Hmm looks like a bunch of Flow errors

I wonder what the difference is between our terms "P2P messages" and "DM"s

Would probably be a good idea to discuss this in my detail in our 1:1 tomorrow. One tradeoff neither of us has mentioned so far about using a single action for all business logic that generates DMOperations is that it might be debugging a little bit more painful.

cherry-pick off master

In D12730#361895, @ashoat wrote:

Looks like @will figured out a solution within the bash script in D12731

I think this can be solved with some smart load balancer & network configuration (IIRC there is a way to prioritize health checks traffic in AWS), but I need to research on what's the best way of doing that. I think we can figure it out later.

This sounds like potentially a better solution, but the current solution in D12731 works for now – agree we can address it later. @will maybe you can create a follow-up task before landing to investigate @bartek's proposal here?

Going to go ahead and try cherry-picking this onto master to fix the failing validator unit test and get rest of stack "more green."

Looks like @will figured out a solution within the bash script in D12731

rebase, look like there are no ESLint issues. There's failing validator that gets fixed in later diff... though maybe it makes sense to cherry-pick D12758 and land it to resolve failing validator test for rest of stack.

Looks like the Flow issue is resolved in D12755, but still would like to see the ESLint fix moved to the diff where the issue is introduced. Let me know if I'm off-base or missing something

But it's inappropriate for use on the client, where we don't expect the keyserver to ever respond with the legacy format.

Love that you included tests! A bit confused about the invariant not matching the types – a couple questions inline

It looks like these validators are used on both the keyserver and the client. It's appropriate for use on the keyserver, which needs to continue supporting older clients.

Actually it seems to be explained in the Test Plan:

CI issues – can you please resolve before asking for review again?

There is a Flow issue. Can you please either pass this diff back to me when it's fully green, or else explain why there need to be CI issues?

Can you fix the CI issues please? The practice of immediately publishing your diff before waiting for CI should only be used for urgent diffs, and if you submit a diff for review with CI issues you should explain / justify why

Actually I must've gotten confused about the CI. I'm actually not seeing any Flow issues, but there do appear to be ESLint issues.

(Passing back to @will)

Rebase before landing

Rebase before landing

Log information about notification encryption failure regardless of user staff member status.

Can you address the CI issues?

review feedback, additional checks and comments

Don't create messages from actions

Rebase

Proposed an optional alternative to error handling

remove timestamp trigger, running only on first rds creation

Can we continue printing the log when this happens, even for non-staff builds?