Open samuel-olivier opened 1 year ago
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.
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...)
Is your feature request related to a problem? Please describe.
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