Remove initial_sync_ended bits

chrome/browser/sync/glue/sync_backend_host.cc

Index: chrome/browser/sync/glue/sync_backend_host.cc
diff --git a/chrome/browser/sync/glue/sync_backend_host.cc b/chrome/browser/sync/glue/sync_backend_host.cc
index 2e275a2501422c5134ad1bdb24904ab8deff3ab1..e272144c5940dba573afd110610a68c718980c40 100644
--- a/chrome/browser/sync/glue/sync_backend_host.cc
+++ b/chrome/browser/sync/glue/sync_backend_host.cc
@@ -676,10 +676,10 @@ void SyncBackendHost::ConfigureDataTypes(
   // downloaded if they are enabled.
   //
   // The SyncBackendRegistrar's state was initially derived from the types
-  // marked initial_sync_ended when the sync database was loaded.  Afterwards it
-  // is modified only by this function.  We expect it to remain in sync with the
+  // detected to have been downloaded in the database.  Afterwards it is
+  // modified only by this function.  We expect it to remain in sync with the
   // backend because configuration requests are never aborted; they are retried
-  // until they succeed or the browser is closed.
+  // until they succeed or the backend is shut down.
 
   syncer::ModelTypeSet types_to_download = registrar_->ConfigureDataTypes(
       types_to_add, types_to_remove);
@@ -692,10 +692,10 @@ void SyncBackendHost::ConfigureDataTypes(
   // prepared to handle a migration during a configure, so we must ensure that
   // all our types_to_download actually contain no data before we sync them.
   //
-  // The most common way to end up in this situation used to be types which had
-  // !initial_sync_ended, but did have some progress markers.  We avoid problems
-  // with those types by purging the data of any such partially synced types
-  // soon after we load the directory.
+  // One common way to end up in this situation used to be types which
+  // downloaded some or all of their data but have not applied it yet.  We avoid
+  // problems with those types by purging the data of any such partially synced
+  // types soon after we load the directory.
   //
   // Another possible scenario is that we have newly supported or newly enabled
   // data types being downloaded here but the nigori type, which is always
@@ -1239,6 +1239,15 @@ void SyncBackendHost::Core::DoInitialProcessControlTypes() {
     return;
   }
 
+  if (!sync_manager_->InitialSyncEndedTypes().HasAll(syncer::ControlTypes())) {

[Nicolas Zea, 2012/12/11 02:12:40]

Could you add a unit test for this case? (i.e. where configuration does not
actually download/apply the control types)

[rlarocque, 2012/12/11 19:23:03]

Good idea.  Done.

+    LOG(ERROR) << "Failed to download control types";
+    host_.Call(
+        FROM_HERE,
+        &SyncBackendHost::HandleInitializationCompletedOnFrontendLoop,
+        false);
+    return;
+  }
+
   // Initialize device info. This is asynchronous on some platforms, so we
   // provide a callback for when it finishes.
   synced_device_tracker_.reset(