Way to determine if feature flag exists

[jsearles]

Is your feature request related to a problem? Please describe.
We would like a way to determine if a flag exists. Currently we have settings that are stored as app settings, feature flags, etc. When evaluating a value we check whether the flag exists in app settings, launchdarkly, etc to obtain the value.

Describe the solution you'd like
The simplest solution would be to expose the IDataStore instance in the LDClient. Alternatively, the GetFlag method could be exposed.

Describe alternatives you've considered
It may be possible that we could use an additional IDataStore instance that we manually create, though that seems less than ideal.

Additional context
Currently we are using the Evaluate call with a null user to LDClient - if the request fails because the flag is missing, then we know that the flag doesn't exist. If it fails because the user is null then we know that it does. This only works because the flag is checked before the user is checked. Obviously this is hacky and has ended up littering our logs and metrics with misleading evaluations.

[eli-darkly]

There is a less hacky workaround— it might or might not meet your needs, but I feel it's worth mentioning. Calling AllFlagsState() will give you a full list of all the flags that exist, and it is guaranteed not to affect your metrics because it does not generate any analytics events. This would be inefficient if you were calling it to check on one flag at a time, since it does evaluate all of the flags, but you could call it once early on and cache the result.

[eli-darkly]

Anyway, regarding the basic idea of adding a "does this flag exist" method, it'd be straightforward to implement and we will definitely consider it. It does exist in at least one other SDK (going back to a time when we weren't as diligent about keeping the feature set consistent across SDKs), and wasn't added elsewhere because there had been very little demand for it as far as we knew. Most applications that use feature flags already know what flags they're using— or, if they are going to try to use a flag that might or might not exist, they are OK with the evaluation showing up in their analytics (I'm not quite clear on what you meant about "misleading evaluations"; maybe you could say more about why you would not want to record an evaluation for the flag even though you are using the flag?). But people do have use cases we don't anticipate.

[eli-darkly]

As for exposing the data store directly in the client API, we would prefer to avoid that; there is a high potential for causing confusion and unintended behavior, and it would make application developers more likely to rely on low-level implementation details as a first resort. That interface is exposed mainly because, in the current architecture, it must be in order to allow database integrations to be implemented outside of the package... but in future versions, the architecture might change in order to reduce that exposure. The more implementation details are exposed, the harder it is for us to make necessary changes to the internal data model to implement new features without having those be breaking changes from an application point of view.

[jsearles]

I called the metrics misleading because we are using a null user to evaluate the flag just to see if it exists - we don't have a user context at the point the check is made. So we are seeing the null calls in metrics and warnings in logs.

AllFlagsState would also requires a user and would be much more expensive. We could use a "dummy" user just to get around this, but i'm not sure that is much better.

I do understand not wanting to expose the IDataStore object. The GetFlag method would be sufficient - we only need to know that the flag exists - not how it evaluates.