sync: Retry soon when server returns conflict

sync/engine/process_commit_response_command.cc

 // Copyright (c) 2012 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/process_commit_response_command.h"
 
 #include <cstddef>
 #include <set>
 #include <string>
 #include <vector>
@@ skipping 153 matching lines @@
     return SERVER_RETURN_TRANSIENT_ERROR;
   } else if (conflicting_commits > 0) {
     // This means that the server already has an item with this version, but
     // we haven't seen that update yet.
     //
     // A well-behaved client should respond to this by proceeding to the
     // download updates phase, fetching the conflicting items, then attempting
     // to resolve the conflict.  That's not what this client does.
     //
     // We don't currently have any code to support that exceptional control
-    // flow.  We don't intend to add any because this response code will be
-    // deprecated soon.  Instead, we handle this in the same way that we handle
-    // transient errors.  We abort the current sync cycle, wait a little while,
-    // then try again.  The retry sync cycle will attempt to download updates
-    // which should be sufficient to trigger client-side conflict resolution.
-    //
-    // Not treating this as an error would be dangerous.  There's a risk that
-    // the commit loop would loop indefinitely.  The loop won't exit until the
-    // number of unsynced items hits zero or an error is detected.  If we're
-    // constantly receiving conflict responses and we don't treat them as
-    // errors, there would be no reason to leave that loop.
-    //
-    // TODO: Remove this option when the CONFLICT return value is fully
-    // deprecated.
-    return SERVER_RETURN_TRANSIENT_ERROR;
+    // flow.  Instead, we abort the current sync cycle and start a new one.  The
+    // end result is the same.
+    return SERVER_RETURN_CONFLICT;
   } else {
     LOG(FATAL) << "Inconsistent counts when processing commit response";
     return SYNCER_OK;
   }
 }
 
 void LogServerError(const sync_pb::CommitResponse_EntryResponse& res) {
   if (res.has_error_message())
     LOG(WARNING) << "  " << res.error_message();
   else
@@ skipping 276 matching lines @@
   // been recursively deleted.
   // TODO(nick): Here, commit_message.deleted() would be more correct than
   // local_entry->Get(IS_DEL).  For example, an item could be renamed, and then
   // deleted during the commit of the rename.  Unit test & fix.
   if (local_entry->Get(IS_DIR) && local_entry->Get(IS_DEL)) {
     deleted_folders->insert(local_entry->Get(ID));
   }
 }
 
 }  // namespace syncer