https://bugs.kde.org/show_bug.cgi?id=399167
--- Comment #19 from David Faure <fa...@kde.org> --- Git commit 8ff596c4fe15199b66262c624d8b7c8d8ec7368f by David Faure. Committed on 21/03/2019 at 15:50. Pushed by dfaure into branch 'Applications/19.04'. Akonadi: fix dangling transaction after itemsync failure Summary: TransactionSequence was emitting result() twice when rolling back. * How did this happen? The TransactionRollbackJob is (automatically) added as a subjob of the TransactionSequence, so when it finishes, slotResult is called (like for all subjobs), as well as rollbackResult(). Since the latter emits result() already [mostly for symmetry with commitResult()], we don't need to do that in slotResult (which doesn't do it for the case of committing, either). * Why is it a problem to emit result() twice? Well, first, it's against the law in KJob world. In practice, ItemSyncPrivate::slotTransactionResult was called twice (for the same TransactionSequence job) which made it decrement mTransactionJobs one time too many. As a result, checkDone() finished too early and didn't go into the "commit transaction" branch for other transactions. Leaving a transaction "open" is a good recipe for database deadlocks further down the line. * Why did the TransactionSequence roll back in the first place? In my case because of the infamous and not-yet fixed "Multiple merge candidates" problem, but it seems that it can also happen when having items without a part, according to Volker's investigations. All of these issues still need to be fixed, but at least akonadi seems to be still usable after they happen. Test Plan: Ctrl+L in kmail, with a folder having multiple items for the same RID Reviewers: dvratil, vkrause Reviewed By: dvratil Subscribers: kfunk, kde-pim Tags: #kde_pim Differential Revision: https://phabricator.kde.org/D19487 (cherry picked from commit f1281cf18f40fd69acd61c31b48f5ce43e138eea) M +0 -2 src/core/jobs/transactionsequence.cpp https://commits.kde.org/akonadi/8ff596c4fe15199b66262c624d8b7c8d8ec7368f -- You are receiving this mail because: You are the assignee for the bug.