fix(sync): re-enqueue periodic work with UPDATE so upgrades re-apply the schedule #114

Merged
JMR-dev merged 2 commits from fix-workmanager-update-policy into main 2026-07-02 08:17:13 +00:00
2 Commits
Author SHA1 Message Date
Jason Ross 791615da06 Merge branch 'main' into fix-workmanager-update-policy 2026-07-02 03:07:05 -05:00
JMR-devandClaude Fable 5 e8c4fc1ea1 fix(sync): re-enqueue periodic work with UPDATE so upgrades re-apply the schedule
Periodic sync, backfill, and prune were enqueued with
ExistingPeriodicWorkPolicy.KEEP, so a newer app version's interval or
constraint change never reached already-installed devices: KEEP pins the job
to the spec from whichever version first scheduled it.

Switch the three periodic schedulers to UPDATE (WorkManager 2.8+; 2.11.2 in
use), which re-applies the current spec on each app-start re-enqueue while
preserving the running period's progress. An unchanged spec is effectively a
no-op, so this never resets the schedule on launch the way REPLACE (cancel +
re-enqueue) would. The one-shot kicks (syncNow/backfillNow/pruneNow) keep
their existing policies -- they are a separate concern from #96.

SyncScheduler now injects Provider<WorkManager> (via a new WorkManagerModule)
instead of calling the WorkManager.getInstance() static directly, so the
policy is unit-testable with MockK; the Provider keeps resolution lazy to
preserve the previous initialization timing.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
2026-07-02 02:27:33 -05:00