Have a robust in memory datastore fallback when the persistent data store connection is not working

[samuel-olivier]

Is your feature request related to a problem? Please describe.

1. Currently if I have a PersistentDataStore (like Redis) that is not reachable when initializing the LaunchDarkly client, when I try to evaluate a feature flag I will receive the defaultValue even though we did receive properly the initial state of the flags from the LaunchDarkly API.
2. Also, if the PersistentDataStore is properly initilialized but connection to Redis is lost later, any update on the feature flags from LaunchDarkly won't be applied until Redis connection is back even though we did receive those updates from the LaunchDarkly api.

Describe the solution you'd like
I think it'd be nice to be able to fallback on the latest known values from the LaunchDarkly api when the connection to the persistent data store is initializing or failing.

Describe alternatives you've considered

• I tried creating a custom implementation of DataStore that has both a PersistentDataStore and a InMemoryDataStore but there are some serialization logic done by PersistentDataStoreWrapper that are not exported and that I don't want to duplicate the code
• For the initialization problem I tried to configure the PersistentDataStore with an unlimited cache, but that implied that the dataStore StatusListener was not updated anymore when the connection was lost
• To solve problem 1 I ended up creating a custom implementation of DataStore that falls back on an InMemoryDatastore when the main dataStore is not initialized but it doesn't solve problem 2.

[louis-launchdarkly]

Hello @samuel-olivier, thank you for reaching out with this request. The persistent store is something that we think about, and have heard similar concerns with the current design (While there is an in-memory cache with the Redis implementation, the state of Redis controls the behavior of the persistent store).

Filed internally as 199320 - I can't promise any timing, but we will discuss this and figure out what we can do in this area.

[leni-kirilov]

I'm hitting Problem 2, as well.

When a Redis connection is lost, I tried setting up a fallback inmemory only client (works ok) , and when Redis is there again, the SDK automatically reconnects to it (and the fallback is no longer used), but until a rule change happens, it will have stale data for the "offline" period.

Also LD docs don't really recommend having more than 1 client per app... so I feel this is a workaround.

Any suggestions on how to address this?
Can I even trust the Redis reconnect in Problem 2?
What is the state of this issue ?

This is putting us in a strange situation if we should use Redis as a datastore at all (besides solving our connectivity issues...)