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.

In D12594#361908, @ashoat wrote:

Hmm looks like a bunch of Flow errors

cherry-pick off master

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."

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.

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

Second: it looks like there's a Flow error here that doesn't show up in the parent diff. Any context?

First: is rawThreadInfoFromServerThreadInfo just for the shimming logic that handles old clients?

address ESLint issues

rebase after resequence

rebase after resequence

resequence

In D12601#357386, @ashoat wrote:

I think it's better to have type suppressions than to have to maintain the old set of types indefinitely. This makes sense to me

JK, the ESLint issue was in revision one before the one that landed. Re-landing.

re-open to address eslint thing

Safe to land out of order since it's purely rename

resequence

Safe to land out of order since it's purely rename

resequence

In D12598#357378, @ashoat wrote:

Is the idea here that we'll never need to decode the permissions on RawThreadInfo again, since we don't store the permissions on the client?

resolve merge conflicts

resolve merge conflict

resolve merge conflicts

resolve merge conflict

resolve merge conflict

rebase and land

rebase and land

We wouldn't want to (for instance) result in a thread being created with no messages, or an account being created with no chats.

JK, this should be the correct logic. Think I got thrown off by

Just jotting down my understanding

Planning changes to do another read through logic

Passing back to figure out what to do if communityMembersToRole isn't present.

fail permission check if we fail to fetch community root

partially address feedback (add comment explaining nullish coalescing w threadID)

update communityMembersToRole within for loop to fallback to threadID if threadInfo.community is null (which means it's a community root itself).

construct communityRootMembersToRole with both threadInfos and communityThreadInfos to handle scenario described here: https://phab.comm.dev/D12543?id=41737#inline-73658 where community root is one of the threadIDs passed into checkThreadsFrozen.

address simple communityRootThread -> communityRootThreadID rename feedback

This was done by @ashoat in D11493.

We ended up going with a very different approach from this stack. Abandoning to tidy things up.

We ended up going with a very different approach from this stack. Abandoning to tidy things up.

We ended up going with a very different approach from this stack. Abandoning to tidy things up.

We ended up going with a very different approach from this stack. Abandoning to tidy things up.

We ended up going with a very different approach from this stack. Abandoning to tidy things up.

remove extraneous import

Abandoning in favor of stack starting with D12594 because lots of things have changed and there's not really 1:1 correspondence with old stack and new stack so I don't think it makes sense to update in place, change a bunch of child/parent diff relationships, etc.

Abandoning in favor of stack starting with D12594 because lots of things have changed and there's not really 1:1 correspondence with old stack and new stack so I don't think it makes sense to update in place, change a bunch of child/parent diff relationships, etc.

Abandoning in favor of stack starting with D12594 because lots of things have changed and there's not really 1:1 correspondence with old stack and new stack so I don't think it makes sense to update in place, change a bunch of child/parent diff relationships, etc.

Abandoning in favor of stack starting with D12594 because lots of things have changed and there's not really 1:1 correspondence with old stack and new stack so I don't think it makes sense to update in place, change a bunch of child/parent diff relationships, etc.

Abandoning in favor of stack starting with D12594 because lots of things have changed and there's not really 1:1 correspondence with old stack and new stack so I don't think it makes sense to update in place, change a bunch of child/parent diff relationships, etc.

Abandoning in favor of stack starting with D12594 because lots of things have changed and there's not really 1:1 correspondence with old stack and new stack so I don't think it makes sense to update in place, change a bunch of child/parent diff relationships, etc.

Abandoning because changes are now included in D12554