Browse Source

Recalculate voting schedule first when getting a new consensus

Because the HS and SR subsystems can use the voting schedule early (with the
changes in #23623 making the SR subsystem using the static voting schedule
object), we need to recalculate the schedule very early when setting the new
consensus.

Fixes #24161

Signed-off-by: David Goulet <dgoulet@torproject.org>
David Goulet 6 years ago
parent
commit
8171d9f50f
1 changed files with 6 additions and 2 deletions
  1. 6 2
      src/or/networkstatus.c

+ 6 - 2
src/or/networkstatus.c

@@ -1939,13 +1939,17 @@ networkstatus_set_current_consensus(const char *consensus,
   }
 
   if (is_usable_flavor) {
+    /* The "current" consensus has just been set and it is a usable flavor so
+     * the first thing we need to do is recalculate the voting schedule static
+     * object so we can use the timings in there needed by some subsystems
+     * such as hidden service and shared random. */
+    dirvote_recalculate_timing(options, now);
+
     nodelist_set_consensus(c);
 
     /* XXXXNM Microdescs: needs a non-ns variant. ???? NM*/
     update_consensus_networkstatus_fetch_time(now);
 
-    dirvote_recalculate_timing(options, now);
-
     /* Update ewma and adjust policy if needed; first cache the old value */
     old_ewma_enabled = cell_ewma_enabled();
     /* Change the cell EWMA settings */