fix: foreground-aware derive-debounce so results are ready when the app opens - #46
Merged
Merged
Conversation
…pp opens DeriveDebouncer previously picked its wait window purely from dataStaleness (how far the last decoded record is from wall-clock now): fresh mode (data staleness < 30min) waits up to 60s quiet / 5min floor, stale/catch-up mode waits 12s/90s. The paradox: as a catch-up sync's incoming records approach "now" — exactly the moment the user is waiting on — staleness drops below the threshold and the debounce flips into its SLOWEST tier. Neither this layer nor DeriveScheduler's own 8s settle knew whether a human was actively watching the screen; the "Analyze now" button felt fast only because it calls DerivationEngine.run() directly, skipping both. Adds a third tier that takes priority whenever the app is in the foreground (5s quiet / 15s floor, reusing the existing `_background` flag AppState already tracks for the derive-scheduler's own foreground gate) — the fresh-mode rationale (avoid paying compute cost for every trickle of ambient live data) doesn't apply when the screen is already on. Background behavior is completely unchanged. 5 new tests covering the foreground tier, including a regression test that existing callers with no isForeground arg behave exactly as before.
Merged
abdulsaheel
added a commit
that referenced
this pull request
Aug 19, 2026
The pin was still sitting on the PR branch head. PR #46 merged it to main as bfea5e5, two commits ahead of the old pin — both test-only deprecation-ignore annotations, lib/ untouched, so no kAlgoVersion bump needed for this move.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
DeriveDebouncerpicked its wait window purely from data staleness — acatch-up sync's incoming records approaching "now" (exactly the moment the
user is watching for) flipped the debounce into its SLOWEST tier (60s
quiet / 5min floor), since neither this layer nor
DeriveScheduler's own8s settle knew whether a human was actively looking at the screen. The
"Analyze now" button felt instant only because it calls
DerivationEngine.run()directly, skipping both debounce layers.Adds a third, foreground-aware tier (5s quiet / 15s floor) that takes
priority over the staleness-based tiers whenever the app is in the
foreground — reusing the
_backgroundflagAppStatealready tracks forthe derive-scheduler's own gate, no new state introduced. Background
behavior is unchanged.
Test plan
DeriveDebouncertests (foreground tier priority, its ownfloor, overriding stale mode, and a regression test proving existing
callers with no
isForegroundarg are unaffected)flutter test --concurrency=1— all greenflutter analyze— no new issues