GitLab

If you configure your Tor client to use a bridge (and maybe you need to also use a pluggable transport to trigger this bug -- dcf did but I don't currently see why), the first time you run it you'll fetch the bridge descriptor and cache it to disk. The act of fetching it and finding it novel will trigger the code in learned_bridge_descriptor():

      if (first) {
        routerlist_retry_directory_downloads(now);
      }

which will spur you to move on to fetch a consensus from your bridge.

But the second time you run it, if it's soon after, you won't find the bridge descriptor novel:

May 14 23:32:14.000 [info] connection_dir_client_reached_eof(): Received server info (size 1165) from server '169.x.x.x:y'
May 14 23:32:14.000 [debug] router_parse_list_from_string(): Read router '$AF9F[...]~Unnamed at 169.x.x.x', purpose 'bridge'
May 14 23:32:14.000 [info] router_load_routers_from_string(): 1 elements to add
May 14 23:32:14.000 [info] router_add_to_routerlist(): Dropping descriptor that we already have for router $AF9F[...]~Unnamed at 169.x.x.x

which means you won't call anything to move on to fetching the consensus. 60 seconds later the timer in main.c will trigger and you'll ask for it.