D19290: Fix intermittent race in collectionattributetest

[David Faure]

dfaure added a comment.


  So I started to write unittests for the following scenario: I create an item with an attribute A, and then one session changes A to A', and the other adds an attribute B -- doing that on a copy of the created item, so it will have AB as attributes, and we want to see if the A in there will overwrite A'. That's what we have in mind here, right?
  
  Well, I realized the following: this can never proceed anyway, even if we fix the second job to not send A. This is because the server looks at the item revision and the second session gets a LLCONFLICT.
  Sure I can do mjob2->disableRevisionCheck() but then are we really testing a real-world scenario here?
  
  If the second session works with a default constructed item, the cmd.oldRevision is -1 and there's no llconflict check.... but then there's no old attribute value lying around in the item, either.
  
  The bug that started all this was the resource setting a GID, which bypasses the revision check -- but then again that means it's not touching attributes, so the above simple-bool solution is good enough too.
  
  What do you think? Should we forget about that possible scenario since it can't happen, or am I forgetting a case where the revision check is more relaxed and we could still have the A' / AB race? (not necessarily a race as in parallel sessions, I guess the same thing can happen in a single session too, at least A+GID overwriting A' can).

REPOSITORY
  R165 Akonadi

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

To: dfaure, dvratil
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/20190301/a6265b46/attachment.html>