This seems risky. If some important dependency changes during auth, the change can be ignored... the effect update will be skipped here, and the old login will be left unchanged. Am I missing something?

How does this get used? I'm a little confused... it seems like the old cookie is used as input to get a new cookie. Will contentSession still be valid after the cookie changes?

It looks like this is addressed in D10844. We convert this ref to state, when means that when it's flipped, the effect is run again

When it comes to notifs session then we are safe. When the keyserver creates new cookie for user then it will see that olm session table in MariaDB is missing notifs session associated with this particular cookie and will ask the client via socket to create new notifs session.

As far as I am concerned there is no similar mechanism for content session. I don't have enough context on content session to tell whether there exists an alternative mechanism to recover from such scenario though.

Good point. D10844 helps a bit, but it also introduces a timeout, but login after important prop changes should happen immediately.

This comment doesn't seem to answer my question, and it only results in more questions...

Let me start by rephrasing my question.

I'm seeing the old cookie passed to notificationsSessionCreator. I'm trying to understand, why is this passed in? The cookie is about to be deleted. What purpose does passing in the soon-to-be-deleted cookie serve?

Next, the new questions posed by your comment.

1. You say in your comment we are "safe". What are we safe from?
2. It sounds like the keyserver will need a new notifs session anyways. Is there any point to this notificationsSessionCreator call, then? Does it immediately get thrown away?
3. You mention the content session, and how there is no "similar mechanism". What mechanism are you referring to? Is there a risk here regarding the content session?

It would also be helpful if we had some way to trigger a login when recoveryInProgress flips to true. I'll think about the best way to do this, and handle it in a separate diff... but figure it makes sense to bring it up here as it may influence your design.

One option would be to lift the login code to a useCallback, and then introduce a separate useEffect that calls it when recoveryInProgress flips to true

In an ideal world, the callback itself would handle "cancelling" the previous invocation of the callback. One way to implement cancellation is to have a function that returns a tuple of [Promise, cancellationFunc]:

let cancelled = false;
const cancellationFunc = () => {
  cancelled = true;
};
const promise = (async () => {
  const someData = await fetchSomeData();
  if (cancelled) {
    throw new Error('cancelled');
  }
  const someOtherData = await fetchSomeOtherData();
  if (cancelled) {
    throw new Error('cancelled');
  }
  ...
})();
return [cancellationFunc, promise];

For dispatchActionPromise, we'd likely have to replace the promise we pass in with a promise that checks cancelled at the very end before returning.

How does this get used? I'm a little confused... it seems like the old cookie is used as input to get a new cookie.

The cookie is used only to store it on the web client. It was implemented in D10245. We added this parameter to the native API as well, just to make it convenient to use in lib, but the value is ignored.

Will contentSession still be valid after the cookie changes?

None of the notif and content sessions depend on the cookie. It is possible that we need a similar mechanism for content sessions, but maybe https://linear.app/comm/issue/ENG-6462/browser-tab-synchronization will fix the issue.

On the server side, we're storing OLM sessions indexed by a cookie D7631. So after a cookie changes, we should either create a new session or rekey an existing one.

I'm seeing the old cookie passed to notificationsSessionCreator. I'm trying to understand, why is this passed in? The cookie is about to be deleted. What purpose does passing in the soon-to-be-deleted cookie serve?

It's used only for storage on the web client side. But if the cookie changes, the stored session will no longer be available, right @marcin? Are we able to fetch this session after the cookie change?

You say in your comment we are "safe". What are we safe from?

Even if the OLM session is lost, the client and the keyserver would communicate over the socket and create a new session. So we're safe from a scenario where cookie change would result in a missing OLM session.

It sounds like the keyserver will need a new notifs session anyways. Is there any point to this notificationsSessionCreator call, then? Does it immediately get thrown away?

We probably can avoid it and rely on creating a session using the socket. But it would be better for both a keyserver and the client to be able to use this session. For the content session, it is even more important because we don't have any code that would fix it.

You mention the content session, and how there is no "similar mechanism". What mechanism are you referring to? Is there a risk here regarding the content session?

The mechanism is about creating a new session using the socket. For the content session, we don't have such a mechanism, so the session won't get recreated. We definitely should find a solution to this issue.

Thanks for explaining. It seems like we have two issues:

1. The keyserver require an initialNotificationsEncryptedMessage for client auth, but the client immediately throws away its notif session after it receives a new cookie, so the entire exchange is wasted.
2. We have no way for a keyserver and client to set up a content session after auth.

We should prioritize resolving both of these.

I agree with everything that @tomek said except for one statement:

But if the cookie changes, the stored session will no longer be available, right @marcin? Are we able to fetch this session after the cookie change?

This isn't true. The session is still stored in the IndexedDB and the client can fetch it. In fact everytime we receive a notif we:

• get all session for all cookies
• sort by cookie id
• for decryption we use the newest cookie id.
• remaining session are deleted

So the session for cookie that was replaced is still available and can be and will be fetched from the db. But it will be deleted soon,