Update: this issue has been resolved.
Our servers have been flaring up since about the start of weekend now. During server storms, there’s some likelihood that applications and servers can begin to disagree on—in our case—timing of edits. Because timing is an important factor in conflict resolution, we’re seeing an increase in reports of conflicted note copies being created. Sometimes this can be caused by edits from multiple devices disagreeing on timing, and other times it can just be one application instance struggling to successfully handle state resolution after a barrage of local changes and variability with network syncing success. Conflicting is a tradeoff between user experience and data integrity. In our case, our applications take the most paranoid approach possible: keeping all differing copies, and very rarely merging copies based on presumption.
However, there are certainly ways to improve this experience. It’s frustrating seeing your notes list populate with conflicts during server flares, and sometimes have the note you’re working on suddenly become conflicted, update its values, and have your previous values moved into another conflicted copy. We try to judge before replacing the current note instance with server changes whether you may be actively editing it, but this threshold also has tradeoffs. A good approach to solving the “productivity disruption” would be to simply aggregate conflicts and keep them unified in one view, rather than displaying all conflicts of a note in your main feed. This would mean that as you type, we never disrupt what you’re working on, and instead light up a bubble in the top right that says “2 Conflicts” that you can address when the time’s right.
We’re actively working on addressing the server flares, and will plan to introduce less disruptive approaches to conflict handling in the near future.
Thanks for reading ✓