Skip to content

5.9.0

Compare
Choose a tag to compare
@eli-darkly eli-darkly released this 08 Oct 00:29
9f17034

[5.9.0] - 2019-10-07

Added:

  • IUserBuilder.AnonymousOptional allows setting the Anonymous property to null (necessary for consistency with other SDKs). See note about this under Fixed.
  • FileDataSourceBuilder.WithSkipMissingPaths allows suppressing file-not-found errors in FileDataSource, if you have a test setup that may add or remove data files dynamically. (Thanks, JeffAshton!)

Changed:

  • It is now possible to specify an infinite cache TTL for persistent feature stores by setting the TTL to a negative number, in which case the persistent store will never be read unless the application restarts. Use this mode with caution as described in the comment for FeatureStoreCacheConfig.Ttl.
  • Improved the performance of InMemoryFeatureStore by using an ImmutableDictionary that is replaced under a lock whenever there is an update, so reads do not need a lock. (Thanks, JeffAshton!)
  • The SDK now has a dependency on System.Collections.Immutable. It refers to version 1.2.0 because the SDK does not use any APIs that were added or changed after that point, but if you want to use that package yourself it is best to declare your own dependency rather than relying on this transitive dependency, since there may have been fixes or improvements in other APIs.

Fixed:

  • IUserBuilder was incorrectly setting the user's Anonymous property to null even if it had been explicitly set to false. Null and false behave the same in terms of LaunchDarkly's user indexing behavior, but currently it is possible to create a feature flag rule that treats them differently. So IUserBuilder.Anonymous(false) now correctly sets it to false, just as the deprecated method UserExtensions.WithAnonymous(false) would.
  • LdValue.Convert.Long was mistakenly converting to an int rather than a long. (CommonSdk #32)
  • FileDataSource could fail to read a file if it noticed the file being modified by another process before the other process had finished writing it. This fix only affects Windows, since in Windows it is not possible to replace a file's contents atomically; in a Unix-like OS, the preferred approach is to create a temporary file and rename it to replace the original file. (Thanks, JeffAshton!)