Avoid unnecessary sync merge conflicts when changing type of new unsynced note or when undoing change of note type

I noticed two cases where I think raising a sync merge conflict is unnecessary as I think the databases should be compatible.

  1. Open the Anki Browser and change the note from type A to type B and then change it pack to type A, without syncing inbetween. It’s basically a manual “undo”, the database should be in the same state as before, except maybe some timestamps.

  2. When a new now is created and the note type is changed directly after creation, without syncing inbetween. I then also get a merge conflict even though the note hasn’t been added at all to the remote database.

I don’t understand databases well or how the syncing protocol works, so not sure how easy this would be to implement. Naively it seems like syncing should work in both cases if Anki would combine several changes into one change prior to syncing. In case 1 Anki could pretend that the note type was never changed in the first place and in case 2 Anki could pretend that the note was created immediately as type B instead of being created as type A and then changed to B. This combination of changes could be done in a pre-sync step. But I’m not sure if this could cause some issues…

1 Like

Detecting situation 1 will not be that straightforward, as you mentioned it’s a manual undo.
Just to be safe Anki marks database as it needs full sync after some actions, for example after changing note type. The situations you mentioned are kind of edge cases, when full sync may not be required, but it will be very complicated to build a resilient mechanism, that will detect all of such cases properly.


Thanks for explaining, and I agree with resilience being a priority and checking for these edge-cases might introduce code-bloat, so I understand it’s not a priority. This is also why I submitted this as a feature suggestion and not a bug. From a pure user-point-of-view this would still be nice to have. I’m not sure if I should mark your answer as a Solution or keep this open just in case somebody finds time to work on this.