Improved Conflict Management for Case Documents

[rjcorwin]

• Implement Case Documents as a log of Actions
  • Store each Action in a log array on the Case Document
  • Each Action gets a UUID
  • Each Action in the log is also a Redux Action
• Replace DiffType with MergeConflictType that detects Actions that conflict in divergent logs
  • Depending on DiffType(s) is like coordinating using diff instead of git that stores the history. Insted use MergeConflictType(s) that are algorithms that check divergent trees for merge conflicts.
  • Example MergeConflictType would be BothStartedEventForm which detects a START_EVENT_FORM action on the same EventForm which would result in two potential Form Response documents for the EventForm to relate to. To resolve, a person would need to decide which corresponding Form Response ID AKA which START_EVENT_FORM Action, should be the winner.
• Refactor Issue UI for Issues of type Merge Conflict that shows divergent tree of Actions and allows the user to resolve them by restacking actions in a new timeline.
  • This is similar in git to resolving a merge conflict of two divergent commits and then using cherry-pick command to prune any changes that would have only made sense in a timeline with the losing Action.
• Refactor Case UI on tablet to lock a Case when in conflict, notify tablet user when one becomes locked, then notify after a sync later that resolves a conflict. In the sync UI maintain a list of Cases in conflict that are locked.
  • This prevents another MergeConflict from happening while the first one is being resolved.
  • This is a compromise that some projects may not be willing to make, locking could be optional.

[chrisekelley]

re: Implement Case Documents as a log of Actions - would this be an immutable log, like a couchdb or (gasp) blockchain?

• How about a checkpoint id or version id for each commit of this log? Or would this simply adding Couchdb on top of Couchdb? Would it be useful instead to store the changes log's seq id? My thinking is to make it easy to see when two logs have become divergent.

[rjcorwin]

(gasp) blockchain

Lol, well for starters in order for a Tablet to write to the log that would require all tablets to be connected to the Internet in order for a network of miners to process Proof of Work or Proof of Stake so that's probably not going to work for most scenarios.

How about a checkpoint id or version id for each commit of this log? Or would this simply adding Couchdb on top of Couchdb?

Sounds like what you are proposing is we put the logs for a Case in the Case's own Document. I think that's one way, another is that each log is its own Document. The latter has the advantage that for each change to a Case, everyone only needs to download the data for that one change, meanwhile if each change for Case was in the Case doc itself, you would be downloading the record of all changes every time there is one change. So, "One Doc Per Change in a Case" vs. "All Changes for a Case in one Doc". The first downside I can think of for "One Doc Per Change in a Case" is that CouchDB would now no longer flag when there is a conflict, that is if the State of a Case is the sum of Log Docs. Tablets would never be writing to the same doc so CouchDB would never catch a conflict. However a trick might be is that when writing a Log Doc you also write some minimal data to the Canonical Case Doc, like toggle a boolean flag on it, then you would generate a revision on a common doc and CouchDB would be able to catch that as a conflict.