$npx -y @buildinternet/releases show rel_md0N85JeKlQde2xzR0qCT
[4.13.0] - 2019-10-10
Added:
It is now possible to specify an infinite cache TTL for persistent feature stores by passing a negative number to the CacheTTL option, in which case the persistent store will never be read unless the application restarts. Use this mode with caution as described in the comments for redis.CacheTTL, dynamodb.CacheTTL, etc.
Changed:
When using a persistent store with an infinite cache TTL (see above), if the SDK receives a feature flag update from LaunchDarkly and is unable to write it to the persistent store because of a database outage, it will still update the data in the in-memory cache so it will be available to the application. This is different from the existing behavior when there is a finite cache TTL: in that case, if the database update fails, the in-memory cache will not be updated because the update would be lost as soon as the cache expires.
When using a persistent store, if there is a database error (indicating that the database may be unavailable, or at least that the most recent update did not get persisted), the SDK will continue to monitor the database availability. Once it returns to normal, if the cache TTL is finite, the SDK will restart the stream connection to ensure that it receives and persists a full set of flag data; if the cache TTL is infinite, it will assume the cache is up to date and will simply write it to the database.