[nofuturekid]

Closes #331

What was wrong

Since 0.1.47 the update notice and its sheet are the only way users learn about updates (ADR-0046), and they could disagree with Settings. Causes, found in the code before changing it:

1. Two copies of the result, not shared. MainViewModel kept _updateState (Overview notice and sheet) and SettingsViewModel kept _checkState (Settings line and button). A check from Settings never reached the notice, and the notice's check ran only once when the app started.
2. Settings checked with the wrong switch position. SettingsViewModel.init calls checkNow(), which used state.value.includePrereleases. That StateFlow is stateIn(WhileSubscribed), so in init nobody subscribes yet and it still holds its default false. With "Include pre-releases" on, opening Settings asked GitHub for stable releases only: Latest available fell back to v0.1.46 with that release's age ("54m ago") while "Last check" said "Just now". "Check now" later used the real value, hence v0.1.47-beta1 again.
3. Switch changes never reached the notice. The notice kept the result it computed under the old setting.

Deviation from the task's guess: there is no stored (DataStore) result and no throttle for the automatic check in the code. Only the time of the last check is stored. Both checks simply run each time (app start, Settings opening).

What changed

• New UpdateTracker (data/update, singleton) is the one holder of the latest known release. App start, Settings opening, "Check now" and the check after the switch all call check(), which reads the switch when it runs and stores its result there. It also records "Last check" as before.
• UpdateTracker.status is what every surface renders: the Overview notice, the update sheet from the notice, the Settings "Latest available" line, the Settings button and the sheet from Settings.
• A result is tagged with the pre-release setting it was computed under and is only shown while that setting is current. Decision: hide at once, then recompute (the switch already starts a check). The alternative, showing the old result until the new one arrives, would offer a beta to a stable-only user for the length of a network call.
• Each check gets a run number; only the newest started check may store its result, so a slow older answer never replaces a newer one.
• A failed check keeps the last good result (the notice and the Settings button stay); Settings shows "Couldn't check" as before. A failure after the switch does not bring back a result of the other setting.
• UpdateStatus.notice(dismissedTag) is the single decision for the notice.
• UpdateRepository.evaluate now picks the newest release above the installed version instead of the first one in GitHub's list order (small related fix, with a test).
• CHANGELOG entry under Unreleased / Fixed.

No timers, retries or polling were added. The result is kept in memory only (a stored copy would have to be thrown away on every app update and every switch change, and the check at app start refreshes it).

Tests

UpdateTrackerTest (11, new) and one new UpdateRepositoryTest case encode why: notice and Settings read one result; the check uses the switch as it is when it runs; switching never leaves the other setting's result on screen; stable-only users are never offered a pre-release; a result not newer than the installed version shows no notice; an older check never overrides a newer one; a failed check keeps the last good result; every check records its time.

The old code cannot host these tests (the view models are not constructible on the JVM, see ResetCertificateTest), so they could not be run against main directly. Instead each rule was checked by breaking the new code on purpose and watching the right tests fail: ignoring the setting tag (2 tests), dropping the run-number guard (1), letting a failure drop the good result (1), not reading the switch (7), and restoring the old "first newer release in list order" (1, theNewestReleaseWinsWhateverOrderGitHubListsThem, which is the only one that tests code that exists unchanged on main).

./scripts/local-ci.sh: passed (lint, debug and release assemble, 267 unit tests, 0 skipped, 0 failed).

Left out on purpose

• The release-notes box in the sheet scrolls and cuts the last visible line without a hint. The design system has no fade or scroll-indicator pattern (only the Sparkline gradient), so nothing was added; a bespoke fade would be a new design decision.
• No version bump, release, .github/ or store-flavor change; no installer code.
• No persistent copy of the result and no throttle (none existed).
• Not verified on a phone; the on-device acceptance of the beta remains with the maintainer.

Follow-ups after review (209504a)

• Progress of a manual check restored. UpdateStatus.checking is true while a check runs; the held result stays. Settings shows "Checking…" in the "Latest available" row again (as on main; the "Check now" button was never disabled on main and still is not). The Overview notice and the "Update to" button keep the held result during a check. A failed check ends the in-progress state and keeps the last good result.

• A check no longer dies with the screen that asked. UpdateTracker runs its checks in an injected application scope (@ApplicationScope, provided by AppModule); check() only requests and waits, so cancelling the requester (leaving Settings) does not lose the answer. Requests under the same pre-release setting join the running check (one network call). A request under a changed setting starts a new check; the older one still ends, but only the newest started check stores its result.

• Tests: 4 new, 1 rewritten (UpdateTrackerTest now 15); each fails when its fix is reverted (checked by mutation). ./scripts/local-ci.sh passed, 271 unit tests, 0 failed, 0 skipped. CHANGELOG unchanged (the user-visible behaviour is the same as described).

• Second review (5e1d512). A check that throws (fetch or the write of the check time) now ends the progress, shows the failure and keeps the held result instead of leaving "Checking…" or crashing the waiting screen; the tracker follows "Include pre-releases" itself (debounce 300 ms, so quick flipping makes one call; collectLatest only so a slow old check does not delay the new one), also when Settings is left right after the flip, and the Settings view model only writes the setting; two tests were added or sharpened (superseded check ending first, two collectors instead of two reads of one flow), 278 unit tests, each new test fails when its fix is reverted.

🤖 Generated with Claude Code