Change Details

We have some logic in reducers to special-case `SET_NEW_SESSION` when a cookie is invalidated. This diff introduces two changes: 1. Now that we have `authoritativeKeyserverID`, I figured we should check it. The only time a `SET_NEW_SESSION` should lead to a state reset is when it's for the authoritative keyserver. 2. I changed it from checking `usingCommServicesAccessToken` to checking `relyingOnAuthoritativeKeyserver`. As long as we rely on an authoritative keyserver, we'll wait until we auth with it before logging the user in. As such, we should treat a deauth with the authoritative keyserver as a logout, and reset the state in that case. 3. I added a check for `relyingOnAuthoritativeKeyserver` to `reduceCurrentUserInfo`, which already had the `authoritativeKeyserverID` check. Separately, something I'm wondering about... in some cases we check `action.payload.sessionChange.cookieInvalidated`, and in others we check `action.payload.sessionChange.currentUserInfo?.anonymous`. Is there any difference in these checks? Should we unify them? Wanted to ask @inka as they have touched this code recently and probably made the same observation. Depends on D11228

We have some logic in reducers to special-case `SET_NEW_SESSION` when a cookie is invalidated. This diff introduces three changes: 1. Now that we have `authoritativeKeyserverID`, I figured we should check it. The only time a `SET_NEW_SESSION` should lead to a state reset is when it's for the authoritative keyserver. 2. I changed it from checking `usingCommServicesAccessToken` to checking `relyingOnAuthoritativeKeyserver`. As long as we rely on an authoritative keyserver, we'll wait until we auth with it before logging the user in. As such, we should treat a deauth with the authoritative keyserver as a logout, and reset the state in that case. 3. I added a check for `relyingOnAuthoritativeKeyserver` to `reduceCurrentUserInfo`, which already had the `authoritativeKeyserverID` check. Separately, something I'm wondering about... in some cases we check `action.payload.sessionChange.cookieInvalidated`, and in others we check `action.payload.sessionChange.currentUserInfo?.anonymous`. Is there any difference in these checks? Should we unify them? Wanted to ask @inka as they have touched this code recently and probably made the same observation. Depends on D11228

We have some logic in reducers to special-case `SET_NEW_SESSION` when a cookie is invalidated. This diff introduces twohree changes: 1. Now that we have `authoritativeKeyserverID`, I figured we should check it. The only time a `SET_NEW_SESSION` should lead to a state reset is when it's for the authoritative keyserver. 2. I changed it from checking `usingCommServicesAccessToken` to checking `relyingOnAuthoritativeKeyserver`. As long as we rely on an authoritative keyserver, we'll wait until we auth with it before logging the user in. As such, we should treat a deauth with the authoritative keyserver as a logout, and reset the state in that case. 3. I added a check for `relyingOnAuthoritativeKeyserver` to `reduceCurrentUserInfo`, which already had the `authoritativeKeyserverID` check. Separately, something I'm wondering about... in some cases we check `action.payload.sessionChange.cookieInvalidated`, and in others we check `action.payload.sessionChange.currentUserInfo?.anonymous`. Is there any difference in these checks? Should we unify them? Wanted to ask @inka as they have touched this code recently and probably made the same observation. Depends on D11228