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

Periodical instead of live sync #2100

Closed
TheSlimvReal opened this issue Nov 23, 2023 · 2 comments · Fixed by #2312
Closed

Periodical instead of live sync #2100

TheSlimvReal opened this issue Nov 23, 2023 · 2 comments · Fixed by #2312
Assignees
Labels
released on @master managed by CI (semantic-release) released managed by CI (semantic-release) Status: Complex Issue advanced, particularly challenging topic that requires extensive knowledge of the code base

Comments

@TheSlimvReal
Copy link
Collaborator

TheSlimvReal commented Nov 23, 2023

We currently use the PouchDB/CouchDB live sync functionality. This is very easy to setup and offers very quick entity updates.

The downside of this approach is that we have very little information about which data is already synchronized and in case of an error, how the app should handle it. At the moment we just restart the live sync and hope nothing has been lost on the way.

An alternative approach would be to periodically (e.g. every 15s) trigger a sync ourselves. This would allow us to check which documents havent been synced yet. This also makes error handling much easier because we can then visualize to the user what data hasn't been synced and what might have been the issue.

The issue in our backend where it keeps using more RAM might also be linked to the live sync and could be resolved with this change.

Approach

  1. As a first prototype the live sync should be replaced with a simple periodical sync leaving everything else as it is. This can be used to check whether it resolves the mentioned backend issue.
  2. If that resolved the problem the next step would be to add visualizers about unsynced changes and improve the error handling. (Indicator for unsynced local changes and manual sync button #412)
@sleidig sleidig moved this from Triage to Priority (Core Team) in All Tasks & Issues Dec 11, 2023
@sleidig sleidig moved this from Priority (Core Team) to Todo [help wanted] in All Tasks & Issues Jan 11, 2024
@sleidig sleidig added Status: Complex Issue advanced, particularly challenging topic that requires extensive knowledge of the code base Status: Core Team Priority labels Feb 13, 2024
sleidig added a commit that referenced this issue Mar 20, 2024
for better error handling
also prevents aborted sync after expired access token

closes #2100, closes #935
@sleidig sleidig moved this from Todo (ready for work) to In Review in All Tasks & Issues Mar 20, 2024
@sleidig sleidig self-assigned this Mar 20, 2024
sleidig added a commit that referenced this issue Mar 22, 2024
for better error handling
also prevents aborted sync after expired access token

closes #2100, closes #935
@github-project-automation github-project-automation bot moved this from In Review to Done in All Tasks & Issues Mar 22, 2024
@aam-digital-ci
Copy link
Collaborator

🎉 This issue has been resolved in version 3.34.0-master.5 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

@aam-digital-ci aam-digital-ci added the released on @master managed by CI (semantic-release) label Mar 22, 2024
@aam-digital-ci
Copy link
Collaborator

🎉 This issue has been resolved in version 3.34.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀

@aam-digital-ci aam-digital-ci added the released managed by CI (semantic-release) label Mar 22, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
released on @master managed by CI (semantic-release) released managed by CI (semantic-release) Status: Complex Issue advanced, particularly challenging topic that requires extensive knowledge of the code base
Projects
Archived in project
Development

Successfully merging a pull request may close this issue.

3 participants