sync: Add non-blocking type encryption support

sync/engine/entity_tracker.cc

 // Copyright 2014 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "sync/engine/entity_tracker.h"
 
 #include "base/logging.h"
 #include "sync/internal_api/public/base/model_type.h"
 #include "sync/internal_api/public/non_blocking_sync_common.h"
 #include "sync/syncable/syncable_util.h"
@@ skipping 175 matching lines @@
   highest_commit_response_version_ = response_version;
 
   // Because an in-progress commit blocks the sync thread, we can assume that
   // the item we just committed successfully is exactly the one we have now.
   // Nothing changed it while the commit was happening.  Since we're now in
   // sync with the server, we can clear the pending commit.
   ClearPendingCommit();
 }
 
 void EntityTracker::ReceiveUpdate(int64 version) {
-  highest_gu_response_version_ =
-      std::max(highest_gu_response_version_, version);
+  if (version > highest_gu_response_version_) {

[Nicolas Zea, 2014/07/30 00:34:15]

It seems like it might be better to do:
if (version <= highest...)
  return

That way old versions have no effect (such as clearing pending commit)

[rlarocque, 2014/07/30 21:56:00]

Done.

+    highest_gu_response_version_ = version;
+
+    // Got an applicable update newer than any inapplicable updates.  It must
+    // be safe to discard the old inapplicable update, if there was one.
+    ClearInapplicableUpdate();
+  }
 
   if (IsInConflict()) {
     // Incoming update clobbers the pending commit on the sync thread.
     // The model thread can re-request this commit later if it wants to.
     ClearPendingCommit();
   }
 }
 
+bool EntityTracker::ReceiveInapplicableUpdate(const UpdateResponseData& data) {
+  if (data.response_version >= highest_gu_response_version_) {

[Nicolas Zea, 2014/07/30 00:34:15]

nit: I find it cleaner to just return early here too if we're not going to do
anything

Also, what is the expected behavior if the version is the same? Receive it or
ignore it? 

[rlarocque, 2014/07/30 21:56:00]

Done.
Technically it shouldn't matter, since the entities will always be identical if
they have the same ID and version.  Whether we decide to treat it as a new
update and apply it, or treat it as an old update and discard it, there should
be no practical effect in the end.

I'm using a bit of subtlety to make the code simpler, though.  In the
ModelTypeSyncWorker, I sometimes use the pattern:

EntityTracker* et = EntityTracker::InitFromUpdate(inapplicable);
et->ReceiveInapplicableUpdate(inapplicable);

That wouldn't work very well if we dropped reflections.

+    highest_gu_response_version_ = data.response_version;
+    inapplicable_update_.reset(new UpdateResponseData(data));
+    ClearPendingCommit();
+    return true;
+  }
+  return false;
+}
+
+bool EntityTracker::HasInapplicableUpdate() const {
+  return !!inapplicable_update_;
+}
+
+UpdateResponseData EntityTracker::GetInapplicableUpdate() const {
+  return *inapplicable_update_;
+}
+
+void EntityTracker::ClearInapplicableUpdate() {
+  inapplicable_update_.reset();
+}
+
 bool EntityTracker::IsInConflict() const {
   if (!is_commit_pending_)
     return false;
 
+  if (HasInapplicableUpdate())
+    return true;
+
   if (highest_gu_response_version_ <= highest_commit_response_version_) {
     // The most recent server state was created in a commit made by this
     // client.  We're fully up to date, and therefore not in conflict.
     return false;
   } else {
     // The most recent server state was written by someone else.
     // Did the model thread have the most up to date version when it issued the
     // commit request?
     if (base_version_ >= highest_gu_response_version_) {
       return false;  // Yes.
     } else {
       return true;  // No.
     }
   }
 }
 
 bool EntityTracker::IsServerKnown() const {
   return base_version_ != kUncommittedVersion;
 }
 
 void EntityTracker::ClearPendingCommit() {
   is_commit_pending_ = false;
 
   // Clearing the specifics might free up some memory.  It can't hurt to try.
   specifics_.Clear();
 }
 
 }  // namespace syncer