[FEATURE] Ignore DISABLED flags from storage layer

[Kavindu-Dodan]

Requirements

Background

According to configuration guideline, when a flag is disabled, it is considered as if it doesn't exisit [1]

When the state is set to "DISABLED", flagd will behave like the flag doesn't exist.

However, in the flagd implementation, we still handle Disabled flags and return errors to evaluation requests.

Desired behavior

PR #670 & #672 improved error handling and introduced bug fixes to disabled flags. Going forward, disabled flags must be ignored from storage which will result in flag not found status matching the configuration guide stated above

[1] -

flagd/docs/configuration/flag_configuration.md

Line 14 in 9490ed6

When the state is set to "DISABLED", flagd will behave like the flag doesn't exist.

[thisthat]

I would not ignore them entirely, but print an "info" or "warning" log message to notify somehow that a flag is disabled.

[toddbaert]

I would not ignore them entirely, but print an "info" or "warning" log message to notify somehow that a flag is disabled.

Ya we could do this when we update the flag state and persist it, or we could keep them in a disabled state and mention it when we evaluate them (though that might add a lot of log-noise... debug might be better in that case).

[Kavindu-Dodan]

Listing down the pros & cons of proposals

Ignore at storage

Pros - Fewer flags in cache (storage), considering that there can be several Disabled flags. And no extra logic for filtering
Cons - If we need a debug log at evaluation time for disabled flags, then we can't do that as we do not have data of disabled flags

Filter at retrieval

Pros - Can provide logs at evaluation time for visibility. Potential future changes (if any) for Disabled flags
Cons - Filtering/check for state is a cost. Storage (cache) must be fast and must contain minimal logic

---

Personally, I am voting to ignore storing Disabled flags with a debug/info log & keep a minimalistic storage layer (i.e- no filtering)

[Kavindu-Dodan]

Had a discussion with @beeme1mr @toddbaert on this.

Ignoring disabled flags at the storage level is problematic as it conflicts with our sync source priority - ignoring a disabled flag at a high priority source is incorrect.

Hence, we will continue to store disabled flags, process them where necessary and produce errors #670 /skip from evaluation #672