On Linear, you estimated that account deletion would take 1 day. Given that this diff updates zero callsites and zero reducers, should we be worried about this estimate? How long do we expect ENG-4357 to actually take?

Last question – what’s the purpose of this new action type, and how does it relate to the existing one? Do we really need two types still? If your view is eg. that the existing action handles deletion from a single keyserver, is this something you’ve confirmed with @inka? Who is going to handle eg. updating the reducer to handle the existing action a different way when your new CSAT constant is set?

@varun and I talked about that delete account from keyserver and from identity will be different actions.

1. Currently, delete account and logout action are reduced in the same way
2. I will be refactoring logout logic in reducers, to be able to clear the state for a subset of keyservers (and to generally clear only the state that is supposed to be cleared on keyserver logout. For example it won't be clearing the CSAT). So reducers will be automatically refactored for delete account from keyserver action. This will allow us to use this action for removing a keyserver from the keyserver list. This is also needed for invalidSessionDowngrade.
3. After recent discussions, we decided that it would be more efficient if I also took care of reducing logout action for identity (see this comment). This is one of the reasons for my rescoping my December goal. This means I will automatically take care of reducers logic for identity delete account, since, if I'm not missing something, it will have the same effect on the redux store as identity logout.

Realized there are no other reviewers. Adding @inka and @tomek (I figure @tomek makes sense since he has been scoping with @inka, and will be looking at ENG-5997)

the deleteUser identity RPC doesn't return anything so I don't think we need an action payload for DELETE_IDENTITY_ACCOUNT_SUCCESS

I assume you're aware of this, but there are some differences, such as how the logout start action is handled in some reducers, but the delete start action is not.

Yes, I just mean that wherever deleteKeyserverAccountActionTypes.success is reduced, logOutActionTypes.success is reduced in the same way. So introducing changes to logOutActionTypes.success gives us changes for deleteKeyserverAccountActionTypes.success, so no additional work will have to be done. And other deleteKeyserverAccountActionTypes (failed, started) are never reduced.

In some cases, @varun's work will be blocked on reducer logic. (...) In this case, does it make sense for @varun to implement some basic reducer logic in services-access-token-reducer.js as part of his logout diff?

Yes, whenever @varun feels blocked we should try to resolve as fast as possible, by either of us implementing the required code. We are messaging and syncing regularly recently, so I think we can work together to keep both of us unblocked. I just need to know if anything I was planing on doing has already been done, so if @varun could subscribe me to those diffs, or add me as a reviewer, that would be great. I will also try to land my diffs regularly, to avoid us duplicating each others work.

Curious what other examples exist like this.

I'm not sure. Generally all of this is pretty intertwined. @varun, can you think of anything else that will soon get blocked on reducers?

I wonder if the DELETE_IDENTITY_ACCOUNT_SUCCESS action needs a payload.

Currently, deleteKeyserverAccountActionTypes's payload is LogOutResult:

export type LogOutResult = {
  +currentUserInfo: ?LoggedOutUserInfo,
  +preRequestUserState: PreRequestUserState,
};

These values are used to:

1. Set currentUserInfo in the store
2. Check invalidSessionDowngrade

According to the scenario described by @ashoat here, I think we still need to check invalidSessionDowngrade for identity logout. So we need both of those values. (currentUserInfo in this context is a LoggedOutUserInfo = { +anonymous: true }. We wanted to remove it, and replace with null/undefined, but I had problems doing so. There is a task tracking this: ENG-5625, and here is a brief explanation of the problems I was facing: comment)
I'm not sure if anything else will be needed in the payload, I can't see why it would be. But if either of us finds out that another value is needed, we will let each other know, and figure out what needs to be done about it.

@varun can you add this payload to this action? See deleteKeyserverAccount for how to do this. Basically preRequestUserState should be in the input of this action, and currentUserInfo should be loggedOutUserInfo, which is a constant defined in lib/actions/user-actions.js

unclear what this android failure is...