If your bridge is near your exit, Tor might surprise you by failing your circuit
In fixing legacy/trac#1090 (moved), we removed the logic that said "if your exit relay and your bridge are on the same /16, and you were about to fail the circuit, ignore the distinctsubnets constraint". This could result in surprising failures for bridge users.
The origin of the problem is that legacy/trac#1090 (moved) decides to follow the user's instructions even when we think they were bad instructions, because the user asked for the behavior explicitly. And I agree with that plan in the case of setting EntryNodes. But a user who sets Bridges might be doing it because he only knows about those bridges, not because he thinks he knows something about path selection strategy that the Tor developers don't know.
So do we keep the user safe by failing any circuits whose exit relays are near her bridges? ("you asked for that behavior, so you get it, sucks to be you") Or do we focus on reachability and back off on our path selection constraints?
One option might be to use the "do I want security or do I want reachability" config option we've been heading toward with legacy/trac#2510 (moved) and legacy/trac#2511 (moved): if we let the bridge cache and try to use bridges that aren't currently configured, we could also make current bridges work rather than fail in this situation.
The Tor client will pick a new exit and try another circuit, so the main effect of the bug is added latency for circuit creation. But there's a slight possibility that we will give up on circuits for an entire minute (after 5 failures). How often does this edge case occur in practice? What if it starts occurring later?
I worry because none of the developers use bridges so few people fix bridge robustness issues.