Ability to look up flag variants by index

[williamgcampbell]

Is your feature request related to a problem? Please describe. It would be nice for the SDK to have more flexible access to feature flag variant details. Two very specific examples would be the ability to lookup feature flag details (values and variations) for a particular flag, and/or the ability to retrieve the feature flag value from a variation index.

Describe the solution you'd like Add a management API interface to the LDClient for looking up EvaluationDetails by key/index or by flag key, without the need for a User.

Describe alternatives you've considered There is an internal data store that the LDClient has. This may have the information necessary and might be a better option to cache the flag information. Currently, this is not exported so it is not an available option.

[eli-darkly]

We've deliberately done our best to keep the flag data model out of the SDK API. In general, we've considered the appropriate scope of SDK functionality to be 1. evaluating flags, 2. generating analytics data. Any kind of "management" functionality is outside of that scope... especially because LaunchDarkly already has a very rich REST API for accessing every part of your data, including flag configurations.

I'm also a little confused about the intended use case. Generally, feature flags are configured to have certain values which will be meaningful to the application. If the application doesn't know what values a flag can have, and has to make a call to get a list of what they can be... how are you making decisions based on flag evaluations?

Also, regarding this part—

looking up EvaluationDetails by key/index or by flag key, without the need for a User

—EvaluationDetail in the LaunchDarkly model always refers to the result of evaluating a flag with regard to a specific user. You can see this because it includes a Reason field, and the Reason cannot be inferred from just the value or variation index, because it depends on the user properties (for instance, you might have received the value true because the user matched a particular rule, or because no rules were matched and the fallthrough value is true). But maybe you weren't thinking of that specific type and just meant "detail" in a general sense.

[williamgcampbell]

But maybe you weren't thinking of that specific type and just meant "detail" in a general sense. That's right.

To give more background it's a common pattern to want request-scoped overriding of feature flag values. In other words, the ability for a client to opt-in to a feature flag variation at the request level, ignoring how the user may typically be bucketed. This is particularly useful to test out the behavior of feature flag bucketing without the overhead of acquiring users that are assigned particular variants or manually assigning users to a variant in the LD admin tool. (assuming you have access)

The overhead of having a separate HTTP client to call the REST API makes that a less desirable option. In a typical evaluation the ldmodel.FeatureFlag is pulled from the datastore, with all available variations anyway. If I were to push for a change today, it might be to expose a new interface that's implemented by the ldclient.LDClient which exposes query access to the underlying datastore.

[cwaldren-ld]

Hi @williamgcampbell, is this feature request still relevant for you at this time?

[williamgcampbell]

Nope, you can close this