D19487: Akonadi: fix dangling transaction after itemsync failure

[David Faure]

dfaure created this revision.
dfaure added reviewers: dvratil, vkrause.
Herald added a project: KDE PIM.
dfaure requested review of this revision.

REVISION 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.
  
  CCBUG: 399167

TEST PLAN
  Ctrl+L in kmail, with a folder having multiple items for the same RID

REPOSITORY
  R165 Akonadi

BRANCH
  Applications/18.12

REVISION DETAIL
  https://phabricator.kde.org/D19487

AFFECTED FILES
  src/core/jobs/transactionsequence.cpp

To: dfaure, dvratil, vkrause
Cc: kde-pim, dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20190303/6c37e21f/attachment.html>