Update dependency LaunchDarkly.ServerSdk to v8

[renovate]

This PR contains the following updates:

Package	Change	Age	Adoption	Passing	Confidence
LaunchDarkly.ServerSdk	5.13.0 -> 8.5.0

---

Release Notes

launchdarkly/dotnet-server-sdk (LaunchDarkly.ServerSdk)

v8.5.0

Compare Source

Features

• adds warning log if excessive StartWaitTime is used. (#​218) (6f6cdec)

v8.4.0

Compare Source

Note: This release is an artifact of our automated release process and contains no significant changes from 8.3.0.

Features

• add support for a Tracing hook implemented via System.Diagnostics, compatible with OpenTelemetry (d9043db)

v8.3.0

Compare Source

Added:

• This release introduces a Hooks API. Hooks are collections of user-defined callbacks that are executed by the SDK at various points of interest. You can use them to augment the SDK with metrics or tracing.

Changed:

• Dropped explicit support for .NET Core 3.1.

v8.2.0

Compare Source

Changed:

• Redact anonymous attributes within feature events
• Always inline contexts for feature events

v8.1.0

Compare Source

Added:

• Added the ability to set wrapper information independent of HTTP configuration. This change is intended primarily for use by LaunchDarkly in the development of wrapper SDKs.

v8.0.0

Compare Source

The latest version of this SDK supports the ability to manage migrations or modernizations, using migration flags. You might use this functionality if you are optimizing queries, upgrading to new tech stacks, migrating from one database to another, or other similar technology changes. Migration flags are part of LaunchDarkly's Early Access Program. This feature is available to all LaunchDarkly customers but may undergo additional changes before it is finalized.

For detailed information about this version, refer to the list below. For information on how to upgrade from the previous version, read the migration guide.

Added:

• A new Migration type which provides an out-of-the-box configurable migration framework.
• For more advanced use cases, added new MigrationVariation and TrackMigration methods on LdClient.
• ApplicationInfo, for configuration of application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.
• Added IsOffline method to ILdClient. This was previously only available on the concrete LdClient implementation.

Removed:

• Remove support for User in LdClient methods. The Context.FromUser method can be used to convert a User to a Context. In a future version it may be removed.

Changed:

• Upgraded LaunchDarkly.EventSource to 5.1.0. This will change the minimum LaunchDarkly.Logging version to 2.0.0 for all dependencies.

v7.1.0

Compare Source

[7.1.0] - 2023-10-16

Deprecated:

• Deprecated methods which take the User type. These methods are removed in 8.0.0. Currently a User can be converted to a Context using Context.FromUser. The ability to do this conversion may be removed in a future version.

v7.0.3

Compare Source

Changed:

• Updated LaunchDarkly.InternalSdk to 3.1.2.

v7.0.2

Compare Source

Fixed:

• Fixed an issue with generating the FullyQualifiedKey. The key generation was not sorted by the kind, so the key was not stable depending on the order of the context construction. This also affected the generation of the secure mode hash for mulit-contexts.

v7.0.1

Compare Source

Changed:

• Update to LaunchDarkly.InternalSdk 3.1.1

Fixed:

• (From LaunchDarkly.InternalSdk) Fixed an issue where calling FlushAndWait with TimeSpan.Zero would never complete if there were no events to flush.

v7.0.0

Compare Source

The latest version of this SDK supports LaunchDarkly's new custom contexts feature. Contexts are an evolution of a previously-existing concept, "users." Contexts let you create targeting rules for feature flags based on a variety of different information, including attributes pertaining to users, organizations, devices, and more. You can even combine contexts to create "multi-contexts."

For detailed information about this version, please refer to the list below. For information on how to upgrade from the previous version, please read the migration guide.

Added:

• In LaunchDarkly.Sdk, the types Context and ContextKind define the new context model.
• For all SDK methods that took a User parameter, there is now a corresponding method that takes a Context. These are defined as extension methods. The SDK still supports User for now, but Context is the preferred model and User may be removed in a future version.
• The TestData flag builder methods have been extended to support now context-related options, such as matching a key for a specific context type other than "user".
• LdClient.FlushAndWait() is a synchronous version of Flush().

Changed (breaking changes from 6.x):

• It was previously allowable to set a user key to an empty string. In the new context model, the key is not allowed to be empty. Trying to use an empty key will cause evaluations to fail and return the default value.
• There is no longer such a thing as a Secondary meta-attribute that affects percentage rollouts. If you set an attribute with that name in a Context, it will simply be a custom attribute like any other.
• The Anonymous attribute in LDUser is now a simple boolean, with no distinction between a false state and a null state.
• Types such as IDataStore, which define the low-level interfaces of LaunchDarkly SDK components and allow implementation of custom components, have been moved out of the Interfaces namespace into a new Subsystems namespace. Some types have been removed by using generics: for instance, the interface type IDataSourceFactory has been replaced by IComponentConfigurer<IDataSource>. Application code normally does not refer to these types except possibly to hold a value for a configuration property such as ConfigurationBuilder.DataStore, so this change is likely to only affect configuration-related logic.

Changed (requirements/dependencies/build):

• .NET Core 2.1, .NET Framework 4.5.2, .NET Framework 4.6.1, and .NET 5.0 are now unsupported. The minimum platform versions are now .NET Core 3.1, .NET Framework 4.6.2, .NET 6.0, and .NET Standard 2.0.
• Applications that use the database integrations for Redis, DynamoDB, or Consul must update to the latest major versions of the corresponding packages (LaunchDarkly.ServerSdk.Redis, etc.).
• There is no longer a dependency on LaunchDarkly.JsonStream. This package existed because some platforms did not support the System.Text.Json API, but that is no longer the case and the SDK now uses System.Text.Json directly for all of its JSON operations.
• If you are using the package LaunchDarkly.CommonSdk.JsonNet for interoperability with the Json.NET library, you must update this to the latest major version.

Changed (behavioral changes):

• The SDK can now evaluate segments that have rules referencing other segments.
• Analytics event data now uses a new JSON schema due to differences between the context model and the old user model.

Removed:

• Removed all types, fields, and methods that were deprecated as of the most recent 6.x release.
• Removed the Secondary meta-attribute in User and UserBuilder.
• The Alias method no longer exists because alias events are not needed in the new context model.
• The InlineUsersInEvents option no longer exists because it is not relevant in the new context model.
• LaunchDarkly.Sdk.Json.JsonException: this type is no longer necessary because the SDK now always uses System.Text.Json, so any error when deserializing an object from JSON will throw a System.Text.Json.JsonException.

v6.3.5

Compare Source

[6.3.5] - 2023-02-27

Changed:

• Update LaunchDarkly.JsonStream to version 1.1.2. This version addresses an issue with serializing doubles to JSON values.

v6.3.4

Compare Source

[6.3.4] - 2023-02-24

Changed:

• Update to LaunchDarkly.JsonStream version 1.1.1. This version includes a fix for parsing double values using the invariant culture.

v6.3.3

Compare Source

Fixed:

• Fixed a bug in the parsing of string values in feature flags and user attributes when they were referenced with date/time operators in a targeting rule. As described in LaunchDarkly documentation, such values must use the RFC3339 date/time format; the SDK was also accepting strings in other formats (for instance, ones that did not have a time or a time zone), which would cause undefined behavior inconsistent with evaluations done by other LaunchDarkly services. This fix ensures that all targeting rules that reference an invalid date/time value are a non-match, and does not affect how the SDK treats values that are in the correct format.

v6.3.2

Compare Source

Fixed:

• When using AllFlagsState to produce bootstrap data for the JavaScript SDK, the .NET SDK was not returning the correct metadata for evaluations that involved an experiment. As a result, the analytics events produced by the JavaScript SDK did not correctly reflect experimentation results.
• Improved efficiency of the logic for processing flag/segment changes, which could cause high CPU usage if there were large numbers of flags. (Thanks, JeffAshton!)
• JSON data produced by AllFlagsState was sometimes larger than necessary due to the inclusion of null properties.
• Network errors on polling requests were being logged at Error level, inconsistent with other equivalent kinds of errors. They now use Warn level.
• If flag updates were unable to be stored due to a database error, the data store status is supposed to reflect this with the error value StoreError. That was not happening.
• The type LaunchDarkly.Sdk.UnixMillisecondTime now serializes and deserializes correctly with System.Text.Json.
• In analytics event data, index events were including an unnecessary contextKind property for anonymous users; this was not in the schema for that type of event and was ignored by LaunchDarkly.

v6.3.1

Compare Source

Fixed:

• The HttpConfigurationBuilder methods Proxy and ConnectTimeout were not working correctly: they were being applied to polling requests and analytics event posts, but not streaming requests. Now they apply to all requests. (#​148)

v6.3.0

Compare Source

Added:

• ConfigurationBuilder.ServiceEndpoints provides a simpler way of setting custom service base URIs, if you are connecting to a LaunchDarkly Relay Proxy instance, a private LaunchDarkly instance, or a test fixture. Previously, this required setting a BaseURI property for each individual service (streaming, events, etc.). If using the Relay Proxy, simply remove any BaseURI calls in your SDK configuration and call ServiceEndpoints(Components.ServiceEndpoints().RelayProxy(myRelayProxyUri)) on the IConfigurationBuilder.
• Convenience methods for working with JSON object and array values: LdValue.Dictionary, LdValue.List, LdValue.ObjectBuilder.Set, LdValue.ObjectBuilder.Remove, and LdValue.ObjectBuilder.Copy.

Fixed:

• When using the adapter that allows SDK types to be deserialized with the System.Text.Json API, temporary JsonDocument instances are now disposed of immediately rather than leaving them to be garbage-collected. (Thanks, JeffAshton!)

Deprecated:

• StreamingDataSourceBuilder.BaseURI, PollingDataSourceBuilder.BaseURI, and EventProcessorBuilder.BaseURI. The preferred way to set these is now with ConfigurationBuilder.ServiceEndpoints.

v6.2.2

Compare Source

There are no functional changes in the SDK in this release; its only purpose is to address the version conflict issue mentioned below.

Fixed:

• Fixed conflicting dependency versions that existed in several LaunchDarkly packages. In .NET Core these would be resolved automatically, but in .NET Framework they could result in runtime assembly loading errors for LaunchDarkly.CommonSdk, LaunchDarkly.Logging, or System.Collections.Immutable, unless binding redirects were used. Note that it may still be necessary to use a binding redirect if your application (or one of its dependencies) relies on an assembly that is also used by the SDK with a different version.

v6.2.1

Compare Source

Changed:

• When event handlers are called for events such as IFlagTracker.FlagChanged, the sender parameter will be the LdClient instance that generated the event. Previously, sender was being set to one of several internal components that were not useful to application code.

Fixed:

• When using IFlagTracker, flag change events would not fire if the data source was FileData and there was a change in the test data file(s). Now, any change to the test data will cause a flag change event to fire for every flag. (#​144)
• A race condition could cause IDataSourceStatusProvider.WaitFor to wait indefinitely or time out even if the desired status was found.

v6.2.0

Compare Source

Added:

• The SDK now supports evaluation of Big Segments. An Early Access Program for creating and syncing Big Segments from customer data platforms is available to enterprise customers.

v6.1.0

Compare Source

Added:

• The SDK now supports the ability to control the proportion of traffic allocation to an experiment. This works in conjunction with a new platform feature now available to early access customers.

v6.0.0

Compare Source

This is a major rewrite that introduces a cleaner API design, adds new features, and makes the SDK code easier to maintain and extend. See the .NET 5.x to 6.0 migration guide for an in-depth look at the changes in 6.0.0; the following is a summary.

Added:

• You can tell the SDK to notify you whenever a feature flag's configuration has changed (either in general, or in terms of its result for a specific user), using LdClient.FlagTracker.
• You can monitor the status of the SDK's data source (which normally means the streaming connection to the LaunchDarkly service) with LdClient.DataSourceStatusProvider. This allows you to check the current connection status, and to be notified if this status changes.
• You can monitor the status of a persistent data store with LdClient.DataStoreStatusProvider. This allows you to check whether database updates are succeeding, or to be notified if this status changes.
• The TestData class in LaunchDarkly.Sdk.Server.Integrations is a new way to inject feature flag data programmatically into the SDK for testing—either with fixed values for each flag, or with targets and/or rules that can return different values for different users. Unlike FileData, this mechanism does not use any external resources, only the data that your test code has provided.
• HttpConfigurationBuilder.Proxy allows you to specify an HTTP/HTTPS proxy server programmatically, rather than using .NET's HTTPS_PROXY environment variable. That was already possibly to do by specifying an HttpClientHandler that had a proxy; this is a shortcut for the same thing.
• HttpConfigurationBuilder.CustomHeader allows you to specify custom HTTP headers that should be added to every HTTP/HTTPS request made by the SDK.
• HttpConfigurationBuilder.ResponseStartTimeout sets the timeout interval for "start of request until beginning of server response", which .NET represents as System.Net.HttpClient.Timeout. The SDK previously referred to this as ConnectTimeout, but it was not a real connection timeout in the sense that most TCP/IP frameworks use the term, so the new name more clearly defines the behavior.
• There is now a DoubleVariation method for getting a numeric flag value as the double type (as opposed to FloatVariation which returns a float).
• The Alias method of LdClient can be used to associate two user objects for analytics purposes with an alias event.
• ConfigurationBuilder.Logging is a new configuration category for options related to logging. This includes a new mechanism for specifying where log output should be sent, instead of using the Common.Logging framework to configure this.
• LoggingConfigurationBuilder.LogDataSourceOutageAsErrorAfter controls the new connection failure logging behavior described below under "behavioral changes".
• The LaunchDarkly.Sdk.Json namespace provides methods for converting types like User and FeatureFlagsState to and from JSON.
• The LaunchDarkly.Sdk.UserAttribute type provides a less error-prone way to refer to user attribute names in configuration, and can also be used to get an arbitrary attribute from a user.
• The LaunchDarkly.Sdk.UnixMillisecondTime type provides convenience methods for converting to and from the Unix epoch millisecond time format that LaunchDarkly uses for all timestamp values.

Changed (requirements/dependencies/build):

• The SDK's build targets are now .NET Standard 2.0, .NET Core 2.1, .NET Framework 4.5.2, .NET Framework 4.7.1, and .NET 5.0. This means it can be used in applications that run on .NET Core 2.1 and above, .NET Framework 4.5.2 and above, .NET 5.0 and above, or in a portable library that is targeted to .NET Standard 2.0 and above.
• The SDK no longer has a dependency on Common.Logging. Instead, it uses a similar but simpler logging facade, the LaunchDarkly.Logging package, which has adapters for various logging destinations (including one for Common.Logging, if you want to keep an existing configuration that uses that framework).
• The SDK no longer has a dependency on Newtonsoft.Json. It uses the System.Text.Json API internally on platforms where that is available; on others, such as .NET Framework 4.5.x, it uses a lightweight custom implementation. This removes the potential for dependency version conflicts in applications that use Newtonsoft.Json for their own purposes. Converting data types like User and LdValue to and from JSON with System.Text.Json will always work; converting them with Newtonsoft.Json requires an extra package, LaunchDarkly.CommonSdk.JsonNet.
• The SDK's dependencies for its own implementation details are now LaunchDarkly.CommonSdk, LaunchDarkly.EventSource, LaunchDarkly.InternalSdk, and LaunchDarkly.JsonStream. You should not need to reference these assemblies directly, as they are loaded automatically when you install the main NuGet package LaunchDarkly.ServerSdk. Previously there was also a variant called LaunchDarkly.CommonSdk.StrongName that was used by the release build of the SDK, but that has been removed.

Changed (API changes):

• The base namespace has changed: types that were previously in LaunchDarkly.Client are now in either LaunchDarkly.Sdk or LaunchDarkly.Sdk.Server. The LaunchDarkly.Sdk namespace contains types that are not specific to the server-side .NET SDK (that is, they will also be used by the Xamarin SDK): EvaluationDetail, LdValue, User, and UserBuilder. Types that are specific to the server-side .NET SDK, such as Configuration and LdClient, are in LaunchDarkly.Sdk.Server.
• Many properties have been moved out of ConfigurationBuilder, into sub-builders that are specific to one area of functionality (such as streaming, or analytics events). See ConfigurationBuilder and Components.
• User and Configuration objects are now immutable. To specify properties for these classes, you must now use User.Builder and Configuration.Builder.
• The following things now use the type LdValue instead of JToken: custom attribute values in User.Custom; JSON flag variations returned by JsonVariation, JsonVariationDetail, and AllFlags; the optional data parameter of LdClient.Track.
• EvaluationReason is now a single struct type rather than a base class.
• LaunchDarkly.Client.Files.FileComponents has been moved to LaunchDarkly.Sdk.Server.Integrations.FileData.
• LdClient.Initialized is now a read-only property rather than a method.
• Interfaces for creating custom components, such as IFeatureStore, now have a new namespace (LaunchDarkly.Sdk.Server.Interfaces), new names, and somewhat different semantics due to changes in the SDK's internal architecture. Any existing custom component implementations will need to be revised to work with .NET SDK 5.x.
• The ILdClient interface is now in LaunchDarkly.Sdk.Server.Interfaces instead of the main namespace.
• The IConfigurationBuilder interface has been replaced by the concrete class ConfigurationBuilder.

Changed (behavioral changes):

• In streaming mode, the SDK will now drop and restart the stream connection if either 1. it receives malformed data (indicating that some data may have been lost before reaching the application) or 2. you are using a database integration (a persistent data store) and a database error happens while trying to store the received data. In both cases, the intention is to make sure updates from LaunchDarkly are not lost; restarting the connection causes LaunchDarkly to re-send the entire flag data set. This makes the .NET SDK's behavior consistent with other LaunchDarkly server-side SDKs.
• However, if you have set the caching behavior to "cache forever" (see PersistentDataStoreConfiguration), the stream will not restart after a database error; instead, all updates will still be accumulated in the cache, and will be written to the database automatically if the database becomes available again.
• Logging now uses a simpler, more stable set of logger names instead of using the names of specific implementation classes that are subject to change. General messages are logged under LaunchDarkly.Sdk.Server.LdClient, while messages about specific areas of functionality are logged under that name plus .DataSource (streaming, polling, file data, etc.), .DataStore (database integrations), .Evaluation (unexpected errors during flag evaluations), or .Events (analytics event processing).
• Network failures and server errors for streaming or polling requests were previously logged at Error level in most cases but sometimes at Warn level. They are now all at Warn level, but with a new behavior: if connection failures continue without a successful retry for a certain amount of time, the SDK will log a special Error-level message to warn you that this is not just a brief outage. The amount of time is one minute by default, but can be changed with the new LogDataSourceOutageAsErrorAfter option in LoggingConfigurationBuilder.
• Many internal methods have been rewritten to reduce the number of heap allocations in general.
• Evaluation of rules involving regex matches, date/time values, and semantic versions, has been sped up by pre-parsing the values in the rules.
• Evaluation of rules involving an equality match to multiple values (such as "name is one of X, Y, Z") has been sped up by converting the list of values to a set.
• If analytics events are disabled with Components.NoEvents, the SDK now avoids generating any analytics event objects internally. Previously they were created and then discarded, causing unnecessary heap churn.
• When accessing a floating-point flag value with IntVariation, it will now truncate (round toward zero) rather than rounding to the nearest integer. This is consistent with normal C# behavior and with most other LaunchDarkly SDKs.
• HttpConfigurationBuilder.ConnectTimeout now sets the timeout for making a network connection, so it is consistent with what is called a connection timeout in other LaunchDarkly SDKs and in most networking libraries. It only has an effect in .NET Core 2.1+ and .NET 5.0+; other .NET platforms do not support this kind of timeout.

Fixed:

• The default value for ConfigurationBuilder.StartWaitTime was documented as being 5 seconds, but the actual value was 10 seconds. It is now really 5 seconds, consistent with other LaunchDarkly server-side SDKs.
• If an unexpected exception occurred while evaluating one clause in a flag rule, the SDK was simply ignoring the clause. For consistency with the other SDKs, it now treats this as a failed evaluation.

Removed:

• All types and methods that were deprecated as of the last .NET SDK 5.x release have been removed. This includes many ConfigurationBuilder methods, which have been replaced by the modular configuration syntax that was already added in the 5.14.0 release. See the migration guide for details on how to update your configuration code if you were using the older syntax.

v5.14.2

Compare Source

Fixed:

• Setting a custom base URI to use instead of the regular LaunchDarkly service endpoints did not work correctly if the base URI included a path prefix, as it might if for instance you were using a reverse proxy that would forward requests from http://my-proxy/launchdarkly-stream/some-endpoint-path to https://stream.launchdarkly.com/some-endpoint-path. In this example, the /launchdarkly-stream part was being dropped from the request URL, preventing this type of proxy configuration from working. Now the base path will always be preserved.

v5.14.1

Compare Source

Fixed:

• The long-running task that the SDK uses to process analytics events was being created in a way that could unnecessarily reduce availability of the managed thread pool, potentially causing unexpected delays in asynchronous task scheduling elsewhere in an application.

v5.14.0

Compare Source

The purpose of this release is to introduce newer APIs for configuring the SDK, corresponding to how configuration will work in the upcoming 6.0 release. These are very similar to the configuration APIs in the recent 5.x releases of the LaunchDarkly server-side Java and Go SDKs.

The corresponding older APIs are now deprecated. If you update to this release, you will see deprecation warnings where you have used them, but they will still work. This should make it easier to migrate your code to the newer APIs, in order to be ready to update to the 6.0 release in the future without drastic changes. For details, see below, and also see the API documentation for IConfigurationBuilder.

Other than the configuration methods, there are no changes to SDK functionality in this release.

Added:

• Previously, most configuration options were set by setter methods in IConfigurationBuilder. These are being superseded by builders that are specific to one area of functionality: for instance, Components.StreamingDataSource() and Components.PollingDataSource() provide builders/factories that have options specific to streaming or polling, the SDK's many options related to analytics events are now in a builder returned by Components.SendEvents(), and HTTP-related options such as ConnectTimeout are now in a builder returned by Components.HttpConfiguration(). Using this newer API makes it clearer which options are for what, and makes it impossible to write contradictory configurations like .IsStreamingEnabled(false).StreamUri(someUri).
• There is a new API for specifying a persistent data store (usually a database integration). This is now done using the new method Components.PersistentDataStore and one of the new integration factories in the namespace Launchdarkly.Client.Integrations. The next releases of the integration packages for Redis, Consul, and DynamoDB will use these semantics.

Changed:

• The components "feature store" and "update processor" are being renamed to "data store" and "data source". The interfaces for these are still called IFeatureStore and IUpdateProcessor for backward compatibility, but the newer configuration methods use the new names. The interfaces will be renamed in the next major version.
• In the newer API, the mode formerly named "LDD" (LaunchDarkly daemon), where the SDK reads feature flags from a database that is populated by the LaunchDarkly Relay Proxy or some other process, has been renamed to ExternalUpdatesOnly. It is now an option for the DataSource configuration method.

Deprecated:

• In IConfigurationBuilder: all methods for setting individual properties related to streaming, polling, events, and HTTP configuration; also, the UseLdd option (see above).
• In Components: DefaultEventProcessor, DefaultUpdateProcessor, InMemoryFeatureStore, NullEventProcessor, NullUpdateProcessor. Replacements for these are described in the API documentation.

v5.13.1

Compare Source

Changed:

• Updated the LaunchDarkly.EventSource dependency to a version that has a specific target for .NET Standard 2.0. Previously, that package targeted only .NET Standard 1.4 and .NET Framework 4.5. There is no functional difference between these targets, but .NET Core application developers may wish to avoid linking to any .NET Standard 1.x assemblies on general principle.

---

Configuration

📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

---

• If you want to rebase/retry this PR, check this box

---

This PR has been generated by Mend Renovate. View repository job log here.