FetchPolicy (SettingsRepository.kt:35) already has a WIFI_ONLY option — full body/attachment
prefetch only on an unmetered network, otherwise behaving like ON_DEMAND
(MailSyncer.kt:140-151/isUnmetered() at :154-158) — but the shipped default is ALWAYS
(SettingsRepository.kt:46, and the DataStore fallback at :73-74), meaning a fresh install
aggressively downloads every message's full body and attachments over cellular by default. Combined with
the mailbox's default full-history backfill (#12, done), that's a meaningful, silent cellular-data cost
for anyone who doesn't know to visit Settings.
Suggested fix
Change the default in both places FetchPolicy.ALWAYS appears as a fallback:
The DataStore-read fallback in Preferences.toAppSettings() (SettingsRepository.kt:73-74)
to FetchPolicy.WIFI_ONLY. The Settings UI (SettingsScreen.kt:105-122) already offers all three
options, so users who want the current aggressive behavior can still opt into ALWAYS.
Acceptance criteria
Fresh installs default to FetchPolicy.WIFI_ONLY.
Existing installs that never touched this setting also read back WIFI_ONLY (the DataStore
fallback, not just the in-memory default, must change).
Any test asserting FetchPolicy.ALWAYS as the default is updated.
Related: #89 (pausing content fetch at low battery, regardless of this setting).
## Problem
`FetchPolicy` (`SettingsRepository.kt:35`) already has a `WIFI_ONLY` option — full body/attachment
prefetch only on an unmetered network, otherwise behaving like `ON_DEMAND`
(`MailSyncer.kt:140-151`/`isUnmetered()` at `:154-158`) — but the shipped default is `ALWAYS`
(`SettingsRepository.kt:46`, and the DataStore fallback at `:73-74`), meaning a fresh install
aggressively downloads every message's full body and attachments over cellular by default. Combined with
the mailbox's default full-history backfill (#12, done), that's a meaningful, silent cellular-data cost
for anyone who doesn't know to visit Settings.
## Suggested fix
Change the default in both places `FetchPolicy.ALWAYS` appears as a fallback:
- `AppSettings.fetchPolicy` default (`SettingsRepository.kt:46`)
- The DataStore-read fallback in `Preferences.toAppSettings()` (`SettingsRepository.kt:73-74`)
to `FetchPolicy.WIFI_ONLY`. The Settings UI (`SettingsScreen.kt:105-122`) already offers all three
options, so users who want the current aggressive behavior can still opt into `ALWAYS`.
## Acceptance criteria
- [ ] Fresh installs default to `FetchPolicy.WIFI_ONLY`.
- [ ] Existing installs that never touched this setting also read back `WIFI_ONLY` (the DataStore
fallback, not just the in-memory default, must change).
- [ ] Any test asserting `FetchPolicy.ALWAYS` as the default is updated.
Related: #89 (pausing content fetch at low battery, regardless of this setting).
Checked against the two open PRs touching this file: PR #46 (fetch-all + retention) adds retentionCount/retentionMonths to SettingsRepository.kt but leaves fetchPolicy: FetchPolicy = FetchPolicy.ALWAYS (data class default and the DataStore fallback) untouched. PR #45 (screen-lock) also edits this file, adding its own unrelated appLock setting — same story, FetchPolicy's default isn't touched. Still open after either merges.
Checked against the two open PRs touching this file: PR #46 (fetch-all + retention) adds `retentionCount`/`retentionMonths` to `SettingsRepository.kt` but leaves `fetchPolicy: FetchPolicy = FetchPolicy.ALWAYS` (data class default and the DataStore fallback) untouched. PR #45 (screen-lock) also edits this file, adding its own unrelated `appLock` setting — same story, `FetchPolicy`'s default isn't touched. Still open after either merges.
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.
Problem
FetchPolicy(SettingsRepository.kt:35) already has aWIFI_ONLYoption — full body/attachmentprefetch only on an unmetered network, otherwise behaving like
ON_DEMAND(
MailSyncer.kt:140-151/isUnmetered()at:154-158) — but the shipped default isALWAYS(
SettingsRepository.kt:46, and the DataStore fallback at:73-74), meaning a fresh installaggressively downloads every message's full body and attachments over cellular by default. Combined with
the mailbox's default full-history backfill (#12, done), that's a meaningful, silent cellular-data cost
for anyone who doesn't know to visit Settings.
Suggested fix
Change the default in both places
FetchPolicy.ALWAYSappears as a fallback:AppSettings.fetchPolicydefault (SettingsRepository.kt:46)Preferences.toAppSettings()(SettingsRepository.kt:73-74)to
FetchPolicy.WIFI_ONLY. The Settings UI (SettingsScreen.kt:105-122) already offers all threeoptions, so users who want the current aggressive behavior can still opt into
ALWAYS.Acceptance criteria
FetchPolicy.WIFI_ONLY.WIFI_ONLY(the DataStorefallback, not just the in-memory default, must change).
FetchPolicy.ALWAYSas the default is updated.Related: #89 (pausing content fetch at low battery, regardless of this setting).
Checked against the two open PRs touching this file: PR #46 (fetch-all + retention) adds
retentionCount/retentionMonthstoSettingsRepository.ktbut leavesfetchPolicy: FetchPolicy = FetchPolicy.ALWAYS(data class default and the DataStore fallback) untouched. PR #45 (screen-lock) also edits this file, adding its own unrelatedappLocksetting — same story,FetchPolicy's default isn't touched. Still open after either merges.