Clients wait for an extra consensus before learning the correct UseGuardFraction value
When clients parse the consensus, they decide whether to register any guardfraction information included based on the value of the UseGuardFraction consensus parameter. The problem is that the decision is taken in the middle of consensus parsing, but in should_apply_guardfraction() we wrongly use networkstatus_get_param(NULL, "UseGuardFraction",..." to decide whether the parameter is on or off. In that case networkstatus_get_param() will check the old consensus, and not the one that we are currently parsing and is still in unfinished state.
comment:52:ticket:9321 includes some possible fixes.
Another possible fix would be to always register guardfraction information found in the consensus. But instead check during path building time whether we should use it or not. So instead of having should_apply_guardfraction() we would have should_consider_guardfraction() or should_use_guardfraction().