Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Feature Request] Periodic retry for failed syncs with configurable policy #677

Open
rocketraman opened this issue Dec 5, 2024 · 0 comments
Labels
enhancement New feature or request

Comments

@rocketraman
Copy link

rocketraman commented Dec 5, 2024

Is your feature request related to a problem? Please describe.

If a value fails to sync to the server it remains in Store, and bookkeeper tracks its sync failure timestamp. However, Store does not attempt to re-sync the value to the server unless that value is fetched. This means that values that are written could potentially stay in the Store for a long time, or even potentially forever if the value is written but never read.

See https://kotlinlang.slack.com/archives/C06007Z01HU/p1733078392404149?thread_ts=1732632234.497909&cid=C06007Z01HU.

Describe the solution you'd like
Store should attempt to re-sync failed values periodically. Ideally the policy for doing so could be configurable, and also ideally there would be some kind of hook that allowed apps to trigger the resync manually. This could be called for example, from Android WorkManager or iOS background jobs to attempt to sync failed values even when the app is closed.

Related to this, I would like a nice API to retrieve information about failed syncs. This could be used to a) display information to the user like "5 items have not yet synced to the server ", and b) schedule and cancel background jobs to retry the sync.

Lastly, some values may never sync to the server because it is malformed or violates server preconditions in some way. Part of the API should allow inspecting the failures for items that have failed to sync and invalidating them i.e. clearing or setting some relevant state in bookkeeper and moving them to some kind of "failed" status in the source of truth.

Describe alternatives you've considered
To have my application code manage the status of failed entries in my local db directly, and then periodically retry sending them to the server via the Updater according to my own retry policies.

Additional Context

I apologize if any of the above is non-sensical -- I'm just getting started with Store and am still learning the concepts and capabilities.

@rocketraman rocketraman added the enhancement New feature or request label Dec 5, 2024
@github-project-automation github-project-automation bot moved this to 🆕 Triage in Store Roadmap Dec 5, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
Status: 🆕 Triage
Development

No branches or pull requests

1 participant