Method to check if a flag exists

[eyalroth]

Is your feature request related to a problem? Please describe.
I would love to have the ability to check with the SDK whether a feature flag exists or not, so I won't try to get its .variation() and receive an error.

Describe the solution you'd like
A method on LDClient with this signature:

export function isFlagExists(key: string): boolean

(I'm not sure whether this is an async function or not, depends on the implementation)

Describe alternatives you've considered
Use allFlagsState() method.

Additional context
Was also requested here.

[kinyoklion]

Hey @eyalroth,

It is important to be clear here that we log an error, or call an error callback, but this isn't an error in the sense of an exception. Generally speaking this represents an interim state in your system, calls it to your attention, and you can know if that is good or bad.

Checking if a flag exists would generally be an anti-pattern that increases the complexity, and likely decreases the robustness, of your code.

const res = client.variation('key', context, false);

if(res) {...}

The flag can come or go and the code works with the default. Versus having to handle two conditions of the flag not existing, and then the desired flag value.

If you don't care about these errors, then you can listen for errors and then ignore them, which prevents them form being logged.

client.addListener('error', () => {
// Ignore flag not found.
continue to log other errors.
});

Basically if you listen for them on the client, we don't default log them.

In the SDK it basically looks like this.

        onError: (err: Error) => {
          if (emitter.listenerCount('error')) {
            emitter.emit('error', err);
          } else {
            logger.error(err.message);
          }

Thank you,
Ryan

[kinyoklion]

An alternative may be a request to reduce the log level of flag not found, for instance to be a warning, or to disable it entirely.

Thank you,
Ryan

[eyalroth]

@kinyoklion I wouldn't necessarily call it an anti-pattern.

Our use case has indeed arose after a misuse of launch darkly in one of our services.
Let's say our service feeds animals. It was written in a way where some animals can be skipped with a feature flag:

function shouldFeedAnimal(name: string, age: number): Promise<boolean> {
  const flagName = `should-feed-${name}`;
  return await client.variation(flagName, { key: age.toString() }, true);
}

Instead, this should have been a single feature flag with rules on top of it. We cannot easily migrate away from this at the moment.

This created a lot of error logs, so someone added an ignore on the specific "missing feature flag" log.
That's problematic, because we do want to be aware of suddenly another unrelated feature flag in the service is missing.

Our current solution is to check if the feature flag exists in the shouldFeedAnimal function before fetching it.

[kinyoklion]

So, generally speaking, we don't want to encourage people to check for feature flags. You do need to in this case because of the dynamic flag name.

Doing one thing in a less than ideal way here has lead to the need for checking if a feature flag exists. Is this flag not formed in a way that you could ignore specifically it? For example in your above flag filtering flags with should-feed-.

Where having a function specifically to check if the flag exists, would lead people toward thinking they need to check that feature flags exist, when in typical feature flag usage they would not. Also often people, unfamiliar with flags, think the presence/absence of the flag should instead be used for control, which additionally encourages less than ideal patterns.

We attempt to keep the interfaces to the SDK standardized, and adding this function is not going to be in consideration. That said I would like to see if there is some alternative, which doesn't lead to confusion and misuse.

Thank you,
Ryan

[eyalroth]

Is this flag not formed in a way that you could ignore specifically it?

@kinyoklion It is, but you never know if some other unrelated flag would have similar format. Besides, it's rather a "messy" solution to ignore specific errors in the logger. I think we'd keep with the workaround until we migrate the flags.

We attempt to keep the interfaces to the SDK standardized, and adding this function is not going to be in consideration. That said I would like to see if there is some alternative, which doesn't lead to confusion and misuse.

I understand. I don't know if there's something that can be made on the API level to avoid this kind of misuse (dynamic flag key). Maybe add a clarification somewhere in the API docs, but nothing concrete.