Restore correct behavior of 0.3.0.4-rc with bridges+ipv6-min

In that chutney test, the bridge client is configured to connect to
the same bridge at 127.0.0.1:5003 _and_ at [::1]:5003, with no
change in transports.

That meant, I think, that the descriptor is only assigned to the
first bridge when it arrives, and never the second.

1 files changed, 8 insertions, 1 deletions

diff --git a/src/or/entrynodes.c b/src/or/entrynodes.c
index 729e4b0391..c3c576c812 100644
--- a/src/or/entrynodes.c
+++ b/src/or/entrynodes.c
@@ -3365,7 +3365,14 @@ guard_selection_have_enough_dir_info_to_build_circuits(guard_selection_t *gs)
    * guards in our list, since these are the guards that we typically use for
    * circuits. */
   num_primary_to_check = get_n_primary_guards_to_use(GUARD_USAGE_TRAFFIC);
-  num_primary_to_check++;
+  /*
+    We had added this to try to guarantee that we'd not normally try a guard
+    without a descriptor, even if we didn't use the first guard.  But it led
+    to problems with the chutney bridges+ipv6-min test.  A better solution is
+    needed.
+
+    num_primary_to_check++;
+  */
 
   SMARTLIST_FOREACH_BEGIN(gs->primary_entry_guards, entry_guard_t *, guard) {
     entry_guard_consider_retry(guard);