remove unused include

modify approach

merge conditions

In D5994#181372, @tomek wrote:

As a test plan, have you also checked creating a new db?

remove try {} catch() {} for background notifs

In D5992#181169, @marcin wrote:

This looks like an inaccurate dependency flow to me. DatabaseManager provides getQueryExecutor method that allows to execute database queries in a way that is agnostic of the type of database used. This means it is an abstraction above SQLiteQueryExecutor, so SQLiteQueryExecutor should not call its methods. Looking at this differential, migrate() of SQLiteQueryExecutor is the only place we call this function from. Perhaps we could implement it here? Or even insert its code directly into relevant places in migrate method (due to its simplicity? Necessary constants to implement this method could be moved to DatabaseQueryExecutor header file or even refactored to some new common header file with database-related constants.

I have a different understanding of the flow here and how things should cooperate here, so let me ask a few questions to establish a common point of view. Sorry if I am not correct in my understanding.

remove log, extract code duplication to separate function

In D5989#180528, @marcin wrote:

I am confused about this reasoning. migrate() is called when SQLiteQueryExecutor constructor is called, which is called exactly once for a thread (thread_local). Therefore calling clearSensitiveData via DatabaseManager::getQueryEXecutor() will not call SQLiteQueryExecutor constructor.

That's not true.
According to the docs of thread_local: If the initialization throws an exception, the variable is not considered to be initialized, and initialization will be attempted again.
(sorry, I didn't linked this in summary but probably I should have done it). This means if the first call will throw an exception (see D5994) and as a result we will try do call clearSensitiveData which will call SQLiteQueryExecutor constructor, and the app will be stuck in a dead loop. Additionally I tested this and I can provide steps if you want to check it empirically.

throw error, update destructing

In D6025#181127, @ashoat wrote:

Regarding the LogInActionSource, I believe we added those to log_in for @kamil's work on the Privacy Policy stuff. While I'm not sure it's needed anymore for that work, it might be useful to know what part of the UI a SIWE request is coming from in the future. That said, we only have one place in the UI for a SIWE request today, and we won't be able to build any sort of "auto-log-in" feature for SIWE... so maybe there's no point to tracking the source, since there will only be one? Probably something we can come back to later.

One more question about the design, I checked Figma and looks like the outline shouldn't break scroll line, is it intended?

Starting reviewing from middle of the stack so adding someone with more context as blocking but I left some comments inline

use useIsFocused hook

update href

fix: move href update to proper diff

fix link href

remove PersistGate

update copy, simplify function definition, fix dependencies

use some, remove special string

update copy, add line height

introduce separate type for pushModal

update type

In D5831#174834, @tomek wrote:

Two visual issues:

1. Loading indicator isn't centered vertically
2. Button height is different when loading indicator is present

remove disabling eslint rule