Just to make sure: sessionRecoveryInProgress isn't persisted, right?

I think that the practice of keeping commented-out types has a big advantage of reducing confusion when searching for older revisions while it doesn't have significant disadvantages.

However, if there is no specialRole field encountered, we will assume we're dealing with a Server/"legacy" type and fallback to sketchy string search.

What is the scenario when this can happen?

We should reintroduce the util (probably as a simple function) if we would need to decide if we can edit / delete a role in some other places.

I don't understand the reason behind this diff and the task from the summary doesn't have any description. Why can't we simply check RoleInfo and its specialRole field?

Fix typo

Fix prop name

Use thread type const.
Update entries test by adding explicit calendar query from the past - the test failed as expected. Updated the dates in entries, which fixed the tests.

In D11166#323019, @atul wrote:

Mostly looks good, but do we need to handle clearing the data on log out/delete account/etc?

Rebase

In D11177#323033, @atul wrote:

Looks good, just want to make sure that this won't break any older clients? I see the following in Test Plan:

Run an older native client and check if it works with new keyserver.

so I'm assuming this table and functionality was never used?

Tested native migration and deleted web migration - we aren't persisting actualizedCalendarQuery on web
and we don't need to migrate it - default state contains a new value.

Fix top-level default keyserver info - the app was crashing because config isn't registered when executing
top-level

Update native state type
Use defaultCalendarQuery function in the default keyserver store
Handle actualizedCalendarQuery from an initial state in the reducer