Chromium Code Reviews
chromiumcodereview-hr@appspot.gserviceaccount.com (chromiumcodereview-hr) | Please choose your nickname with Settings | Help | Chromium Project | Gerrit Changes | Sign out
(935)

Unified Diff: sync/engine/backoff_delay_provider.cc

Issue 1553433002: [Sync] Sync should run canary cycle after any network related error (Closed) Base URL: https://chromium.googlesource.com/chromium/src.git@master
Patch Set: Fix android test Created 4 years, 11 months ago
Use n/p to move between diff chunks; N/P to move between comments. Draft comments are only viewable by you.
Jump to:
View side-by-side diff with in-line comments
Download patch
Index: sync/engine/backoff_delay_provider.cc
diff --git a/sync/engine/backoff_delay_provider.cc b/sync/engine/backoff_delay_provider.cc
index cb8b0f198c4488a1127d1452ff0b5f6f373a94f9..864401cc9c9cb390d24cfbed446f97cacf5ed0e8 100644
--- a/sync/engine/backoff_delay_provider.cc
+++ b/sync/engine/backoff_delay_provider.cc
@@ -65,27 +65,13 @@ TimeDelta BackoffDelayProvider::GetDelay(const base::TimeDelta& last_delay) {
TimeDelta BackoffDelayProvider::GetInitialDelay(
const sessions::ModelNeutralState& state) const {
- // NETWORK_CONNECTION_UNAVAILABLE implies we did not even manage to hit the
- // wire; the failure occurred locally. Note that if commit_result is *not*
- // UNSET, this implies download_updates_result succeeded. Also note that
- // last_get_key_result is coupled to last_download_updates_result in that
- // they are part of the same GetUpdates request, so we only check if
- // the download request is CONNECTION_UNAVAILABLE.
- //
- // TODO(tim): Should we treat NETWORK_IO_ERROR similarly? It's different
- // from CONNECTION_UNAVAILABLE in that a request may well have succeeded
- // in contacting the server (e.g we got a 200 back), but we failed
- // trying to parse the response (actual content length != HTTP response
- // header content length value). For now since we're considering
- // merging this code to branches and I haven't audited all the
- // NETWORK_IO_ERROR cases carefully, I'm going to target the fix
- // very tightly (see bug chromium-os:35073). DIRECTORY_LOOKUP_FAILED is
- // another example of something that shouldn't backoff, though the
- // scheduler should probably be handling these cases differently. See
- // the TODO(rlarocque) in ScheduleNextSync.
+ // NETWORK_CONNECTION_UNAVAILABLE implies we did not receive HTTP response
+ // from server because of some network error. If network is unavailable then
+ // on next connection type or address change scheduler will run canary job.
+ // Otherwise we'll retry in 30 seconds.
if (state.commit_result == NETWORK_CONNECTION_UNAVAILABLE ||
state.last_download_updates_result == NETWORK_CONNECTION_UNAVAILABLE) {
- return short_initial_backoff_;
+ return default_initial_backoff_;
}
if (SyncerErrorIsError(state.last_get_key_result))
« no previous file with comments | « chrome/browser/sync/test/integration/sync_exponential_backoff_test.cc ('k') | sync/engine/backoff_delay_provider_unittest.cc » ('j') | no next file with comments »

Powered by Google App Engine
This is Rietveld 408576698