Feature store cache ignored prior to initialization

[farioas]

Is this a support request? no

Describe the bug We're using Redis as a feature store cache. The logs are full of warning saying Feature Flag evaluation attempted before client has initialized.

To reproduce Client initialization:

store = Redis.new_feature_store(
    url=settings.REDIS_LOCATION,
    prefix='feature-flags',
    caching=CacheConfig(expiration=30))
ldclient.set_config(Config(
    settings.FEATURE_FLAGS_API_KEY,
    feature_store=store,
    http=HTTPConfig(connect_timeout=5)
))
client = ldclient.get()

uwsgi short config:

enable-threads = True
lazy-apps = True

! Note: we're using lazy-apps mode, it will load an application one time per worker instead of preforking.

Expected behavior There should be no warnings, because the feature store cache should be consulted prior initialization.

Logs

{"asctime": "29/Nov/2022:12:41:28 +0000", "name": "ldclient.util", "funcName": "_evaluate_internal", "lineno": 296, "levelname": "WARNING", "user_id": null, "message": "Feature Flag evaluation attempted before client has initialized - using last known values from feature store for feature key: ff_some_flag_redacted"}

SDK version

launchdarkly-server-sdk==7.5.0

Language version, developer tools Python 3.8.10 uwsgi 2.0.21

OS/platform Ubuntu 20.04

Additional context The issue is very similar to https://github.com/launchdarkly/java-server-sdk/issues/107

[eli-darkly]

I may be misunderstanding your description of the issue, but this seems to me to be intended behavior rather than a bug. I'll explain what the intention was.

• The "initialized" state is defined as "the SDK has successfully connected to LaunchDarkly and received at least an initial set of current flag data."
• The SDK does allow your code to proceed with using the client even if it is not yet in an initialized state, because we don't want to completely block startup of an application if there are problems connecting to LaunchDarkly. We always want graceful degradation, where the SDK does the next best thing to whatever it cannot do.
• If we're using a database integration, and there is already some flag data in the database, then graceful degradation is defined as "the SDK uses the last known flag data from the database." If there was not any data, then it would have to be "the SDK returns the application-defined default value for every evaluation."
• However, "last known flag data from the database" is still by definition not the current flag data. Applications normally do want to use the current flag data from LD; evaluating flags when the SDK is not yet in an initialized state, while allowable, is an unusual and not-ideal condition. Therefore we log a warning, to make sure you're aware that that's what is happening.

[eli-darkly]

That is standard behavior across all of our server-side SDKs that have any database integrations.

[eli-darkly]

In other words, unless I'm misunderstanding your report, it is not "ignoring" the Redis cache. If there is flag data in Redis, and you do a flag evaluation, then the SDK will log a warning, but it should also be reading the flag data from Redis and using it to do your evaluation.

~I have some uncertainty here because you didn't mention the full log line— there are actually two different possible log messages that include the text you mentioned. And you also didn't mention whether the flag evaluation is in fact returning a reasonable value based on what the flag data in Redis was. But what I would expect is that the flag evaluation would use that flag data, and that the full log line would be this:~

(Update: sorry, I just reread your message and saw where you quoted the full log line. And indeed it was the one that I expected, which is this one:)

Feature Flag evaluation attempted before client has initialized - using last known values from feature store for feature key: <your flag key>

If it did not see any data in Redis, then it would be:

Feature Flag evaluation attempted before client has initialized! Feature store unavailable - returning default: <the default value parameter that you passed to variation()>

It is explicitly telling you that it is "using last known values from feature store", i.e. the cached data in Redis.

[farioas]

Thanks for such a detailed explanation, this should be published somewhere in documentation, especially sequence from your 1st message as a sequence diagram.

[eli-darkly]

Yes - I've asked the documentation team to look into making this clearer in docs.