This seems pretty difficult to review... will break down this diff further

rebase before landing

Change dependencies arrays, fix interval, clearTimeout as effect cleanup, fix array type.

Rebase

Comments

Update to new threadHashingStatus

Added comments and migrations. Extracted array chunking logic to utils. Fix issues with new action and types.

Replaced by D9349

We've talked about this, but heads-up that in terms of sequencing, I'm thinking of that one as a sort of a "follow-up" to the multi-keyserver launch... we could launch with the expectation that users input keyserver URLs manually.

In D9279#274672, @ashoat wrote:

how often are we rotating the token?

This question does not appear to have been answered

In D9279#273116, @varun wrote:

how often are we rotating the token?

Fix

This diff was really hard to review. I wish somebody else could have done it, but @patryk's limited time to address his regression here (I was told that he had 4 hours) made me feel like I had to be personally involved in order to fix master and unblock releases again ASAP.

Added the comment for ENG-4516 to revert this when the issue is complete. Should be good to land.

Before landing, please add a comment to ENG-4516 to make sure this change is reverted when that task is completed

Change regex

I have some questions, if those don't make sense I'll try to unblock this as soon as possible

@marcin should be back tomorrow, but might need some time to catch up on things... might be good to add another reviewer to this

how often are we rotating the token?

In D9331#274297, @atul wrote:

might make further sense to pull out to separate test data file?

In D9325#274666, @ashoat wrote:

This ensures that we'll only ever need to update the specific message spec in one place if we ever want to change this.

Would we also need to update the ValidRawSidebarSourceMessageInfo type introduced in D9324?

This ensures that we'll only ever need to update the specific message spec in one place if we ever want to change this.

Use more functional approach

Address review

Address review + changes due to review for D9217

Related to: https://phab.comm.dev/D9295#274628
There is no reverting change, I've added the phrase Revert D[number] as part of the D9320 test plan and phabricator treated this as a reverting change for this diff 😳😳

Fix type

In D9320#274599, @tomek wrote:

Can you expand the test plan a little bit by e.g. checking that a modal doesn't show for logged-out users?

In D9295#273224, @tomek wrote:

Is it valid to require policy acceptance only when a user is logged in? When a user isn't logged in, we don't allow them to do much, but I'm wondering, if from the legal perspective, we should require them to agree to something.

Make the approach more consistent

Fix reducer bug

In D9257#272801, @kamil wrote:

Not a fan of keeping the solution with mutating input, but accepting this since fixing this is not a part of this work. Maybe we can at least create a task to improve this?

Add early return and use more functional approach

Can you expand the test plan a little bit by e.g. checking that a modal doesn't show for logged-out users?

Unify names

After changes to D9217 this diff is no longer needed

Simplify

Chenge implementation to allow dividing data per keyserver. Reasoning explained here: https://linear.app/comm/issue/ENG-4440/refactor-redux-fields-second-iteration-refactor-actions#comment-f5d6c650

Looks great, but there are a couple of issues.