ItemSync: Fix full sync and transaction handling
* Ensure that checkDone doesn't start the next batch while we're still fetching the items. This bug was triggered only if setFullSyncItems was called at least twice in streaming mode (therefore it only appeard on large imap folders where the items we delivered in two batches, and only during the flag sync which is a full sync). The first call triggered the ItemFetch, but while that was in progress, the second call went via process() to checkDone(), which cleared mProcessingBatch and immediately started a second parallel batch, and a third batch was started by deliveryDone(). This resulted in the first two batches (20 items), appearing as new (because the were processed before the local items were fetched), and the already locally available items getting deleted, because they couldn't be removed from mUnprocessedLocalIds (since they were processed before entering that list. We use the job counter to lock, just like everywhere else. * mTransactionJobs should not be checked in execute(), as it is already checked in checkDone(), and the check in execute() is only valid when using MultiTransactionMode. * Adapted the test to the discovered problems. * The fetchjobs need to be part of the transaction as well, as they are otherwise not executed before the transactoin is complete. REVIEW: 117608
parent
14edc959
Please register or sign in to comment