D19487: Akonadi: fix dangling transaction after itemsync failure

[David Faure]

dfaure added a comment.


  In fact mTransactionJobs in ItemSync isn't really a counter. It's always either 1 (when we have a current transaction) or 0. So it's used as a bool, but in this bug it would go down to -1, and up to 0 when it should be 1. Any objections against making it a bool to make that code more robust? It's technically not the same as (mCurrentTransaction != nullptr) because mCurrentTransaction is set to nullptr immediately after calling commit() in checkDone(), before slotTransactionResult is called (I guess to avoid adding more subjobs to it while it's committing? Or is there no purpose in doing that, and therefore mTransactionJobs is useless even as a bool?).
  
  Now back to debugging the case where the user cancels. I think this hits the "TODO cancel subjobs" comment in TransactionSequence::rollback()....

REPOSITORY
  R165 Akonadi

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

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/c6cff929/attachment.html>