however, my local keyserver/mariadb isn't designed to handle switching between false and true.

What do you mean by that? After you go with https://www.notion.so/commapp/Running-two-keyservers-0d373941f2494d949846da02752b91db instructions, you can change the client's flags however you want - at least that's what I'm doing and it works reliably. So my keyserver is always configured in a multi-keyserver manner.

Update a comment

Fix a comment

Add a comment

Simplify

Not going to block it, but the approach doesn't make too much sense to me. Introducing something just to be removed a little later could be avoided by a better sequencing of work.

Are there any actions that need ops processing dispatched before we render TunnelbrokerProvider?

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