Handle syncing with non-auth keyservers

Is native also affected by this bug?

Will test generally at end to make sure things work as expected.

Is this something that will be done later in the stack?

I think you should consider having a test plan that actually verifies that this logic is correct.

1. What is a scenario when this could happen?
2. Why do we need an additional handler - isn't removing the token associated with a logout action?
3. How the callLogOut method could work? It uses an authenticated Identity client, which requires the access token when calling its functions. Before every call to it, we call ensureThatWorkerClientAuthMetadataIsCurrent which would try to create a wrapper without an access token.

I'm still thinking through what format that interface will take. I could consider including this functionality in that shared interface when I get there.

Sounds great!

It seems like we can extract the logic to lib by creating a function that accepts three functions: for fetching the stamped user ID, clearing the DB, and stamping the DB. What do you think about doing this?

Rever changes to import ordering

Always delete the old item

Is it possible that due to some internal keyserver error the cookie will change and the keyserver will request the client to create new notifs session but new notifications session creation will execute before the effect is executed? In such case the old session would overwrite new one.

Maybe... it would require two things to happen almost at the same time: 1. keyserver sending new cookie 2. keyserver noticing that a notif session should be recreated. Going to think about it, but it sounds really unlikely to happen.

After thinking about this it seems to be an extreme edge case. I think we can protect ourselves against it by reassigning only when the target item isn't set - that would mean that we created a new session for the new cookie. Unfortunately, this still leaves us with an even less probable race condition: localForage doesn't have an API that allows atomic "set if not present" operation, so it's still possible for an item to be set after we check and before we set a new one.

Add some protection against edge cases

Should we regenerate a wasm file?

In D11649#334825, @marcin wrote:

I would amend to the test plan some steps that try to recreate race condition when we log in multiple pages at the same time. We should expect that after logging in to all pages we can see multiple notifs sessions in IndexedDB but when the notifs is received we can decrypt it and it removes all but one notif session.

Fix reassignment logic

Rebase

Rename

Can't we simply reload the page when the client version is unsupported?

In D11659#334906, @ashoat wrote:

In D11659#334885, @tomek wrote:

Why moving this code to CommHybrid fixes the issue?

I believe because it executes later. More details here. My thinking was that it's safe to call from CommHybrid, since it's called from CommCoreJSIModulePackage.getJSIModules.

Since by that point other JSI libraries (presuamably including Expo libraries) seem ready for setup, I figured it was safe to call SecureStore from that location.

Why moving this code to CommHybrid fixes the issue?

Do we need a dedicated validator for UpdateRelationshipMessage?