search

Tangerine-Community / Tangerine

Digitize your offline data collection. Create your Forms online with Tangerine Editor, conduct them offline with the Tangerine Android App. All results you collect can be exported as a CSV file, easy for processing in a spreadsheet. Tangerine has been used in over 1 million assessments and surveys in over 60 countries and in 100 languages.
http://www.tangerinecentral.org/
GNU General Public License v3.0
49 stars 29 forks source link

Inconsistent sync results when conflicts are detected. #2484

Open lachko opened 3 years ago

lachko commented 3 years ago

It seams that we always preserved whoever synced the conflict first. Do we want to preserve the data of whoever was more persistent and clicked sync again and again until no errors were detected, or do we want to get the last (or first) datetime created. Also a different sequence of sync start gives a different result - scenario 3 and 4 should yield the same data but they do not.

I think that the current setting opens the door for inconsistent conflict resolutions that depends on who clicks the button first rather then on who created the record first.

Scenario 1 Tablet A Fills in and Syncs Tablet B Fills in and syncs - Error on, must press Sync again Tablet A syncs Update conflict - syncs again B Syncs no error no conflicts Result: B is everywhere

Scenario 2 Tablet A Fills in Tablet B Fills in and syncs Tablet A Syncs - Get update conflict, Press start again update conflict , press again no errors B Syncs - Error update conflict , Press again no errors A syncs no errors Result: A is on the server

Scenario 3 Tablet A Fills in Tablet B Fills in Tablet A Syncs Tablet B Syncs - doc update error, start again A syncs - update error, click start again Result: B is on the server

Scenario 4 Tablet A Fills in Tablet B Fills in Tablet A Syncs Tablet B Syncs - doc update error, do not sync Tablet A sync again - no errors Sync B again no errors Results A is everyone now

rjcorwin commented 3 years ago

@lachko @mfinholt @chrisekelley I think we've found many strange behaviors related to automatic conflict resolution (automerge), not sure this is a regression so I wouldn't want to block the release for this. My guess is getting this right will take a substantial investment of LoE. If y'all agree, then I propose we add a autoMergeConflicts boolean flag to app-config.json that would allow us to turn off automerge on projects until the kinks are ironed out. When autoMergeConflicts is set to false, it could still create an issue to flag the conflict. Then we resolve the conflict manually in Fauxton.

rjcorwin commented 3 years ago

@lachko @mfinholt @chrisekelley It turns out detecting unique/new merge conflicts is trickier than I first thought. I've split that functionality out into a new ticket for v3.16.0 (https://github.com/Tangerine-Community/Tangerine/issues/2492). For v3.15.0, setting "autoMergeConflicts": false in client/app-config.json will result in just turning off auto merge, database conflicts will remain, no issue will be logged, but we now have a syncConflicts view we can use to monitor database conflicts via CouchDB Fauxton. I've outlined this in the v3.15.0 CHANGELOG in this change.

  • If using Sync Protocol 2, the "Auto Merge" feature that tries to fix database conflicts is now off by default and database conflicts will not be logged as Issues. If you would like to keep it on, set "autoMergeConflicts": true in your group's client/app-config.json file. However be aware that turning this on will result in inconsistent results (https://github.com/Tangerine-Community/Tangerine/issues/2484). Monitoring for database conflicts can now be done by monitoring the syncConflicts view via CouchDB Fauxton.
rjcorwin commented 3 years ago

The above is now available in v3.15.0-rc-13.

lachko commented 3 years ago

Confirming that the setting works. Let's decide on how to resolve the auto conflicts in the next release

chrisekelley commented 3 years ago

Here is a scenario I discussed wit @lachko that we need to test: This error can be reproduced when you simply open a case on a tab, don't add anything - it can over-write any data (from a conflict) that is from another tab and is "new".