<table><tr><td style="">dfaure added a comment.
</td><a style="text-decoration: none; padding: 4px 8px; margin: 0 8px 8px; float: right; color: #464C5C; font-weight: bold; border-radius: 3px; background-color: #F7F7F9; background-image: linear-gradient(to bottom,#fff,#f1f0f1); display: inline-block; border: 1px solid rgba(71,87,120,.2);" href="https://phabricator.kde.org/D19487">View Revision</a></tr></table><br /><div><div><p>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?).</p>

<p>Now back to debugging the case where the user cancels. I think this hits the "TODO cancel subjobs" comment in TransactionSequence::rollback()....</p></div></div><br /><div><strong>REPOSITORY</strong><div><div>R165 Akonadi </div></div></div><br /><div><strong>REVISION DETAIL</strong><div><a href="https://phabricator.kde.org/D19487">https://phabricator.kde.org/D19487</a></div></div><br /><div><strong>To: </strong>dfaure, dvratil, vkrause<br /><strong>Cc: </strong>kde-pim, dvasin, rodsevich, winterz, vkrause, mlaurent, knauss, dvratil<br /></div>