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?

Rename

Update the comment

NOTE: The request constructed on the client will currently fail. We need to update both validators and responder on keyserver to support this new format.

A safer ordering might be to first introduce the support for a new format on the keyserver, gated behind code version, and then modify the format on the client.

Not sure if we still need this - the Linear issue has been canceled for a long time.

We don't have the tests anymore and the service is now written in Rust.

Delete empty string checks. Move clearing the metadata to clearSensitiveData. Stop running secure store functions on the DB thread.

Delete unnecessary conditions

Handle null user and update the comment

The task from the title https://linear.app/comm/issue/ENG-536/sidebar-list-modal-re-style - is marked as done. If we decide to do something more about that issue, it would be probably easier to do it from scratch instead of figuring out how to make this stack solve the problem.

The task from the title https://linear.app/comm/issue/ENG-536/sidebar-list-modal-re-style - is marked as done. If we decide to do something more about that issue, it would be probably easier to do it from scratch instead of figuring out how to make this stack solve the problem.