Automatic recovery from Multiple Merge Candidates error

Authored by dvratil on May 28 2019, 10:47 AM.



Introduce a recovery codepath when Multiple Merge Candidates error
occurs during Item merging. Since clients generally do not use
merging, this really only happens during ItemSync. In such case we
quitely delete all the conflicting items from the database and reschedule
the collection sync. The next sync should then succeed and bring the
collection into a consistent state.

Note that this does not fix the Multiple Merge Candidates bug - it can
still happen (and we still don't know how), but Akonadi should now be
able to recover from it automatically without user intervention, thus
making this issue less of a PITA.

CCBUG: 338658

Test Plan

Successfuly auto-recovered a broken collection on my setup.

Diff Detail

R165 Akonadi
Automatic diff as part of commit; lint not applicable.
Automatic diff as part of commit; unit tests not applicable.
dvratil created this revision.May 28 2019, 10:47 AM
Restricted Application added a project: KDE PIM. · View Herald TranscriptMay 28 2019, 10:47 AM
Restricted Application added a subscriber: kde-pim. · View Herald Transcript
dvratil requested review of this revision.May 28 2019, 10:47 AM
dvratil edited the summary of this revision. (Show Details)May 28 2019, 10:50 AM
dvratil added a reviewer: KDE PIM.

+1, this looks ok to me, but a second opinion from @dfaure would probably be a good idea.

dfaure accepted this revision.May 31 2019, 8:58 AM

Just one typo, looks good otherwise.


I guess this line isn't actually needed due to the HACK HACK in the recover method, but let's keep it, it looks clean, unlike the hack ;)




This makes me realize that I don't remember ever seeing the duplicates in the kmail message list.
So the duplicates must be created by itemsync itself, not by something that happens before...

This revision is now accepted and ready to land.May 31 2019, 8:58 AM
dvratil added inline comments.May 31 2019, 11:13 AM

Yes, well the HACK HACK HACK will go away once I'm done with the "server-side" ItemSync, since that will get us rid of the client-side transactions completely, so calling commit will actually do a commit.


You would only notice if the duplicates were actually duplicates of a single message rather than two distinct messages with conflicting RIDs.

Which makes me realize I should add some way of disabling the automatic recovery because otherwise debugging the source of the MMC error will be even more difficult if it will auto-correct itself immediately.

This revision was automatically updated to reflect the committed changes.
hook added a subscriber: hook.Jun 19 2019, 11:04 AM

Does this perhaps also solve the following bug? It seems somewhat related.