Good bridge + bad bridge = no bootstrap

Summary

If I configure tor with one known-good bridge and one known-bad bridge (e.g. the host is simply not a bridge) then tor refuses to bootstrap.

(By the way, in Tor Browser the UX is pretty bad in this situation, because Tor Launcher just stays at 70% progress and never reports an error to the user.)

What is the current bug behavior?

We get stuck with:

May 17 11:10:35.000 [info] I learned some more directory information, but not enough to build a circuit: We're missing descriptors for 1/2 of our primary entry guards (total microdescriptors: 6540/6540). That's ok. We will try to fetch missing descriptors soon.

What is the expected behavior?

I expected tor to ignore the bad bridge and successfully bootstrap using only the good bridge.

Environment

This is the case both in Tails, Debian Sid and Tor Browser 10.0.16.

Possible fixes and discussion

I wonder, if this is not a bug, is this because even when using bridges, tor tries to respect guard-n-primary-guards-to-use/NumEntryGuards? If so there seems to be an exception when only one (know-good) bridge is provided, because then bootstrapping works. Is all this expected/intended? Or am I confused?

Taking a step back, to me it seems harsh on users to enforce something like NumEntryGuards for user-configured bridges since it puts a lot of responsibility on them to ensure at least two are working, with no clear way for them check that (basically, they have to read and understand the logs). Otherwise the software used to configure tor (e.g. Tor Launcher, or its replacements) has to get better at detecting individual bridge failures and give the user some way to drop bad ones.