Missing edge case in sync protocol?

[Nils-TUD]

I'm starting to use vdirsyncer to sync my local caldav/carddav files with remote servers and stumbled upon a potential issue in the sync protocol. I've read the Offline-IMAP article, the extension for vdirsyncer, and also looked at the code. I think I have roughly understood it, but I am not sure if I missed something.

As far as I understand this code, it only considers whether the side a or b changed. If both changed, there is a conflict. But what if neither side changed, but the content is still different? That case is currently ignored and I'm not sure if that's correct/desired.

The reason I stumbled upon this is that I actually have this case. Unfortunately I can't explain how it ended up in this state (that shouldn't be possible right?), but looking at the sqlite DB, that's what I'm seeing:

$ sqlite3 calendar.items
SQLite version 3.47.2 2024-12-07 20:39:59
Enter ".help" for usage hints.
sqlite> SELECT ident,hash_a,hash_b,etag_a,etag_b FROM status WHERE hash_a != hash_b AND etag_a != etag_b;
0fd01608-1706-4d35-b419-d3f7a5d2b970|7918cbb87ba27a45c48f1c2a5c0436268c2bdecb1d4a476d8c866d08ca281d03|d1162fe61e45c4d0f055bf208325b4ed1127482333b6930b919004e94d852cd0|1733143526760558336.000000000;9605993|"3fe13874942281a359abc79ad2ac5301"
c0021124-dc75-486e-b791-b0ef2eb3ea87|4b42e849fda093d3c25e85cb9d8c05fe45d5f59119f78a2b51bbcab5549ad1e5|1f850c5eb7b794a9a7f4e94a38baccbc3d1cab267515bf54937278ef87447391|1733463051495150592.000000000;9598652|"96f2a8ce71ac7405d31feab12482a0f3"
...

So there are multiple items where the local side has a different hash than the remote side. And I also checked the calendar entries on both sides and verified that they are indeed different. And just to be clear: syncing again does not change anything as these items did not change since the last sync, but are already different. So, it stays in this state unless I change either side in which case it will just silently overwrite the other side. I could probably just delete the status directory to work around it for now. But being able to reach this apparently broken state is problematic as I would like to rely on vdirsyncer in the future.

My questions are:

1. Am I missing something or is that indeed a state that should never be reached? If the latter, does anybody have an idea how it was possible to reach that state?
2. Should the case that neither side changed, but both hashes exists and are different be handled? To me it sounds like this should also result in a conflict.

Some info, if required:

• vdirsyncer version: 0.19.3
• Python version: 3.13.1
• OS: Arch Linux