Do not apply 'max_failures' to random-exponential schedules.

Fixes bug 20536; bugfix on 0.2.9.1-alpha.

2 files changed, 15 insertions, 3 deletions

diff --git a/changes/bug20536 b/changes/bug20536
new file mode 100644
index 0000000000..9e0dd164bb
--- /dev/null
+++ b/changes/bug20536
@@ -0,0 +1,6 @@
+  o Major bugfixes (download scheduling):
+    - When using an exponential backoff schedule, do not give up on
+      dowloading just because we have failed a bunch of times.  Since
+      each delay is longer than the last, retrying indefinitely won't
+      hurt. Fixes bug 20536; bugfix on 0.2.9.1-alpha.
+
diff --git a/src/or/directory.h b/src/or/directory.h
index 9477948aa0..629b3ead90 100644
--- a/src/or/directory.h
+++ b/src/or/directory.h
@@ -114,9 +114,15 @@ static inline int
 download_status_is_ready(download_status_t *dls, time_t now,
                          int max_failures)
 {
-  int under_failure_limit = (dls->n_download_failures <= max_failures
-                             && dls->n_download_attempts <= max_failures);
-  return (under_failure_limit && dls->next_attempt_at <= now);
+  if (dls->backoff == DL_SCHED_DETERMINISTIC) {
+    /* Deterministic schedules can hit an endpoint; exponential backoff
+     * schedules just wait longer and longer. */
+    int under_failure_limit = (dls->n_download_failures <= max_failures
+                               && dls->n_download_attempts <= max_failures);
+    if (!under_failure_limit)
+      return 0;
+  }
+  return dls->next_attempt_at <= now;
 }
 
 static void download_status_mark_impossible(download_status_t *dl);