[Bug]: Boolean Flags never return reason "FLAG_DISABLED_EVALUATION_REASON", and `enable` not working

[Tai-ch0802]

[Bug]: Boolean Flags never return reason "FLAG_DISABLED_EVALUATION_REASON", and `enable` not working

[erka]

@Tai-ch0802 thank you for your report. It works for variant flag type, but is broken for boolean flag type. We will fix it shortly.

@markphelps is it any chance to include the fix into v1.36?

[erka]

@GeorgeMac thank you for the explanation.

I would say that I would expect only false value for the flag just looking on the Flags page.

[GeorgeMac]

@erka I see what you're saying there. Perhaps we can come up with some better way to visualize boolean flags in the list view. One thing might to make it clear that is default: disabled and that there are e.g. n conditions which could change that.

[GeorgeMac]

In case of emergency there are few ways to handle changing flag to always return true or always return false.

One way is to just remove all the rollouts. The rollouts are the things which can short-circuit the flag and change the value from the default. This is perhaps a little more tenable with e.g. the git backend, because you have Git history and version control, which you can restore and revert once you want to get back to the state you were in before. In you want to not loose track of how the flag was configured before removing rollouts.

A second way is to change the value on each rollout to be the same as the default. This has the same effect, but leaves the definitions intact if you don't want to loose them. So you can just change the values back when you want to start progressively enabling it again.

A third way is to just add a threshold or segment rule that always matches every request and have it return either true or false as the first rollout rule. For example, percentage == 100% or matching a segment with 0 constraints. This will short-circuit to always return the value on that first rollout.

I think we definitely could do better explaining this in the documentation. I wonder too whether there are just some things we could do in the UI to make this clearer. Just trying to see if there is a way to not incur a breaking change and working with the existing data model, as we're strongly committed to preserve backwards compatibility.

[GeorgeMac]

Thanks for raising this @Tai-ch0802 🙏 I think there is definitely something here we can improve.
You're not the first person to find this confusing and it was much a topic of discussion when designing the boolean flag in this way.

[GeorgeMac]

Sorry @erka and @Tai-ch0802 this is actually behaving as expected.

https://www.flipt.io/docs/concepts#rollouts

With boolean flags, evaluation happens serially over the rollouts until a condition is true.
If a condition is true, then it returns the value associated with the matching rollout.

The enabled property on a boolean flag is the last condition of the set of rules and is what everything defaults to when other conditions do not match. In this situation, the flag is behaving as expected, because it matched the segment and returned the Value associated with the rollout.

This was an intentional difference added when we created the boolean type flag, which separates it from the variant type flag. The Variant type flag treated the enabled property as a hard kill switch. Where boolean type flags treat it as the default value when other conditions do not match (e.g. segment or threshold).

[GeorgeMac]

The flag demonstrated above can be broken down into this sequence of conditions:

• if matches segment all-user return true
• else return default, which is false (where default is the enabled base property on the flag)

[GeorgeMac]

The flag disabled reason predates boolean type flags. It came from the variant type flag, when we only had one type of flag.
We could re-introduce it when the returned value is false I suppose.

But it had more intentional meaning for the variant type flag, which could be enabled / disabled in its entirety. There was no match on segments, because the flag was hard disabled. Where a boolean type flag is more of a value (true or false) which you're trying to resolve based on some context. Like some remote boolean variable.

[Tai-ch0802]

.@GeorgeMac @erka  thank you both.

@GeorgeMac You mentioned one important thing, HARD KILL SWITCH.
I think there are two different things, both important.

• hard kill switch
• policy in 'default deny all' or 'default accept all'

Is there any possibility of handling these?
Maybe there is another property to control the policy of default value.
The existing property 'enable' for the hard kill switch.

If 'hard kill switch' exists in the boolean flag either, there will be more useful and intuitive.

[Tai-ch0802]

I got it. Thank you for suggestions.
I'll close this bug issue.

In case of emergency there are few ways to handle changing flag to always return true or always return false.

One way is to just remove all the rollouts. The rollouts are the things which can short-circuit the flag and change the value from the default. This is perhaps a little more tenable with e.g. the git backend, because you have Git history and version control, which you can restore and revert once you want to get back to the state you were in before. In you want to not loose track of how the flag was configured before removing rollouts.

A second way is to change the value on each rollout to be the same as the default. This has the same effect, but leaves the definitions intact if you don't want to loose them. So you can just change the values back when you want to start progressively enabling it again.

A third way is to just add a threshold or segment rule that always matches every request and have it return either true or false as the first rollout rule. For example, percentage == 100% or matching a segment with 0 constraints. This will short-circuit to always return the value on that first rollout.

I think we definitely could do better explaining this in the documentation. I wonder too whether there are just some things we could do in the UI to make this clearer. Just trying to see if there is a way to not incur a breaking change and working with the existing data model, as we're strongly committed to preserve backwards compatibility.