Rebase

Readonly

Rever import ordering change

Address review

It's unfortunate how different native and web are, but I think it makes sense given the technical decisions we've made

When we receive the version we compare it, if it's different this tab is old, we refresh it - download the newest web app version, and connect to the new worker.

Are there any risks here? Can the refresh fail, or be stopped by a user?

Rebase

Format

Rebase

Rebase

Improve error handling

Use event emitter

Fix Flow

Fix error handling and capturing

Rebase

Modify function signature

Wondering about the consequences of this rename. It feels like it could break the compatibility of our reports - an older report could contain one of registerActionTypes actions that can't be recognized by the more recent code.

Wondering about the impact on the keyserver - if all the clients use HTTP, it might result in a lot of open HTTP connections. Also, from the client's point of view, it might result in a lot of open connections (probably more than a browser allows). So I think we should move only some requests to HTTP, but I might be wrong.

Debugged it a bit and figured out what's going on. It seems like the Identity service doesn't recognize ashoatKeyserverID to be an ID of Ashoat's user. Instead, in identity-users table there's an entry for the user whose value is some UUID (different for staging and prod). After using the ID from the table, this code works correctly.

In D10403#301009, @varun wrote:

what's not working?

I would guess that failing to process the reports also shouldn't cause clearing the db - if we fail the operation, we won't save a report, and by clearing the db we're making things a little worse.

This diff still has an issue: when calling a new keyserver, it returns sessionChange which causes setNewSession to be dispatched - this results in the keyserver being added to a store in an incorrect way and breaks more things down the line.

In D10157#299660, @inka wrote:

I wanted to move reducing loading statuses to web and native reducers altogether, but I couldn't overcome a flow problem:
I don't want to copy the reduceLoadingStatuses reducer to web and native, so it is located in lib. It takes an action: BaseAction. I was unable to type it in a way that wouldn't cause errors. If I make the action be an inexact BaseAction, like flow docs suggest: action: {...BaseAction, ...}, then I get errors about read-only properties, as the action I'm passing into the function has nested read-only fields, and the action that is being taken by the reducer was stripped of all read-only.
This works, because setNewSessionActionType, logOutActionTypes and deleteAccountActionTypes are in BaseAction
I know this is not ideal, but it fixes the issue, and is way less hacky than the previous solution.

Looks a lot cleaner!

Probably fix the override. This still requires a lot of testing and thinking about
memoization, but it isn't broken in an obvious way.

Use optional

Use the correct key in overrides. Tested it by specifying keyserver override in web link
handler.

const validateLink = useVerifyInviteLink({
  keyserverID: ashoatKeyserverID,
  keyserverURL: 'http://localhost:3000/keyserver',
});

This calls the proper endpoint, but causes some other issues - e.g. invite link
verification assumes that a user is logged in, which isn't always true when using an invite
link. Going to fix this in the next diffs.

I'm going to check the option of using MariaDB transactions to minimize the number of possible race conditions

This solution is hacky - we're discarding loading statuses of requests that will be resolved later. Instead, we should reduce loading statuses before we check invalidSessionDowngrade.

I don't think there was a good reason behind this await