Brittle behavior when running with bridges and NumEntryGuards=2
During my experiments in #40157 (closed) I noticed that my Tor client would stop working in the middle of the experiment when I was running with bridges and two guards (
[notice] Application request when we haven't used client functionality lately. Optimistically trying known bridges again.
I found out that if one of the two bridges was down, Tor stops working because
guard_selection_get_err_str_if_dir_info_missing() could not find the descriptor of that bridge, and would report it as missing directory info and block circuit attachments in
This does not seem like the right behavior because one of the two bridges is still up and we should be using that instead of completely giving up.
More investigation is needed to find out if this can happen if a user has configured more than one bridges but has
NumEntryGuards=1 (the default). Or if this can ever happen with regular guards and
The fix might be to special case bridges here, or to make our guard dirinfo logic a bit more intelligent.
[As a smaller bug here,
guard_selection_get_err_str_if_dir_info_missing() is set to 3 in the case of two bridges and
NumEntryGuards=2 which is inaccurate because we don't have three primary guards. I don't think this has an effect on the behavior though.]