Add capability of listening for feature flag value changes.

[erecarte]

I'd like to create a LaunchDarkly backend for Spring Cloud Config. It's basically an integration for Spring where you look up properties the usual way in Spring, and internally Spring will ask LaunchDarkly for the value of that property.

In order to do that, I'd need to know when feature flags change to trigger a refresh event in Spring's environment.

Right now there doesn't seem to be an option of registering a listener in the client to know when things change, unless I completely overwrite a few classes? Would it be possible to add it?

[jkodumal]

That seems generally useful. Would an event listener pattern work for you?

[erecarte]

Sounds good! Maybe some event listener for which you get an event with the feature flags that were changed or something like that?

[erecarte]

Hi @jkodumal, any idea if this is something that will be worked on soon? Would you need help? Thanks!

[jkodumal]

This is something that we were looking to start in a few weeks, but we'd be happy to receive contributions and work with you on it if you need this sooner.

[efenderbosch]

Any update on this? Was thinking of writing it myself.

[eli-darkly]

This fell off of our roadmap at some point - sorry for the lack of follow-up. I think in order for us to implement this, we would need to define the use cases a little better, for instance:

• Does "the flag has changed" mean that the flag's value is now different when evaluated with a specific user; or does it mean that some property of the flag was changed in the LD app, regardless of whether that actually causes a value change for any user?
• What if the flag's own properties have not changed, but some prerequisite flag (or user segment) that it depends on has changed, so that you may now get a different result?

In order to be able to address the second point, I think this would probably have to be written by us rather than an external developer, because it would depend on details of the flag and segment data model which are intentionally not public (I mean, you can always see what the JSON structure of them is, but we keep them non-public in the Java code so that data model changes won't break things).

On the other hand, if all that matters is the simplest case in the first point (i.e. you just want to know if a flag has been edited), the implementation would be simpler: basically, you would use a FeatureStore implementation that delegates all methods to the underlying feature store, and triggers the "flag has changed" logic whenever upsert is called. But that would not be a particularly useful implementation for anyone who uses prerequisites and/or segments.

[eli-darkly]

This feature will be in the 5.0.0 release. A beta release of 5.0.0-rc1 is coming this week, so watch the releases in this repository if you're interested in trying it out early.

[eli-darkly]

For anyone who is curious, the beta release— which includes this notification feature— is out now, and we are hoping to release the real 5.0.0 within a couple of weeks.

[eli-darkly]

The 5.0.0 release is finally out, and the API for this new feature is slightly different from the beta releases. There are two ways you can listen for flag changes. First, to be notified of any flag configuration change, regardless of whether that change actually affects the value for any particular user:

    client.getFlagTracker().addFlagChangeListener(changeEvent -> {
        System.out.println("Someone has modified this flag: " + changeEvent.getKey());
    });

For this type of event, the only information given is the flag key; it is just a notification that some type of change has happened, so you may want to re-evaluate that flag for whatever users you are interested in.

The other method is for more specifically monitoring the value of a specific flag for a specific user:

    LDUser user = new LDUser("some-user-key");
    client.getFlagTracker().addFlagValueChangeListener("special-flag", user, changeEvent -> {
        System.out.println("The value has changed from " + changeEvent.getOldValue()
            + " to " + changeEvent.getNewValue());
    });

If you have a flag that does not have any user targeting rules, but is just on or off for everyone, so the user properties do not matter, you would still use this method— just as you always have to provide some user properties when you call boolVariation, stringVariation, etc.

For more information, see FlagTracker.