Surfaced during the max-effort code review of PR #46 (default fetch-all history + device-only retention). Below the cut of the reported/fixed findings — filed for tracking.
Problem.DatabaseModule.provideDatabase runs runBlocking { settingsRepository.settings.first() } and runBlocking { keyStore.passphrase() } while Hilt constructs the singleton LibreMailDatabase. That work (a DataStore read + a Keystore op, possibly a SQLCipher re-key conversion) executes synchronously on whichever thread first injects the database — which can be the main thread — so first DB access can jank or ANR.
Impact. Startup/first-open latency; potential ANR on slow devices, especially when encryptCache is on (the conversion runs here).
Suggested fix. Move the encryption gate off the injection path (e.g. lazily open on a background dispatcher, or perform the passphrase/conversion in an init step before the DB is first touched) so no blocking I/O runs during Hilt construction. Pre-existing (not introduced by #46).
_Surfaced during the max-effort code review of PR #46 (default fetch-all history + device-only retention). Below the cut of the reported/fixed findings — filed for tracking._
**Problem.** `DatabaseModule.provideDatabase` runs `runBlocking { settingsRepository.settings.first() }` and `runBlocking { keyStore.passphrase() }` while Hilt constructs the singleton `LibreMailDatabase`. That work (a DataStore read + a Keystore op, possibly a SQLCipher re-key conversion) executes synchronously on whichever thread first injects the database — which can be the main thread — so first DB access can jank or ANR.
**Location.** `app/src/main/kotlin/org/libremail/di/DatabaseModule.kt` (`provideDatabase`).
**Impact.** Startup/first-open latency; potential ANR on slow devices, especially when `encryptCache` is on (the conversion runs here).
**Suggested fix.** Move the encryption gate off the injection path (e.g. lazily open on a background dispatcher, or perform the passphrase/conversion in an init step before the DB is first touched) so no blocking I/O runs during Hilt construction. Pre-existing (not introduced by #46).
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Surfaced during the max-effort code review of PR #46 (default fetch-all history + device-only retention). Below the cut of the reported/fixed findings — filed for tracking.
Problem.
DatabaseModule.provideDatabaserunsrunBlocking { settingsRepository.settings.first() }andrunBlocking { keyStore.passphrase() }while Hilt constructs the singletonLibreMailDatabase. That work (a DataStore read + a Keystore op, possibly a SQLCipher re-key conversion) executes synchronously on whichever thread first injects the database — which can be the main thread — so first DB access can jank or ANR.Location.
app/src/main/kotlin/org/libremail/di/DatabaseModule.kt(provideDatabase).Impact. Startup/first-open latency; potential ANR on slow devices, especially when
encryptCacheis on (the conversion runs here).Suggested fix. Move the encryption gate off the injection path (e.g. lazily open on a background dispatcher, or perform the passphrase/conversion in an init step before the DB is first touched) so no blocking I/O runs during Hilt construction. Pre-existing (not introduced by #46).