Go SDK

[6.0.0] - 2022-12-07

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."

This feature is only available to members of LaunchDarkly's Early Access Program (EAP). If you're in the EAP, you can use contexts by updating your SDK to the latest version and, if applicable, updating your Relay Proxy. Outdated SDK versions do not support contexts, and will cause unpredictable flag evaluation behavior.

If you are not in the EAP, only use single contexts of kind "user", or continue to use the user type if available. If you try to create contexts, the context will be sent to LaunchDarkly, but any data not related to the user object will be ignored.

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 go-sdk-common, the new package ldcontext with the types Context and Kind defines the new context model.
• The ldtestdata 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 5.x):

• The SDK packages now use regular Go module import paths rather than gopkg.in paths: gopkg.in/launchdarkly/go-server-sdk.v5 is replaced by github.com/launchdarkly/go-server-sdk/v6 and gopkg.in/launchdarkly/go-sdk-common.v2 is replaced by github.com/launchdarkly/go-sdk-common/v3.
• The type lduser.User has been redefined to be an alias for ldcontext.Context. This means that existing application code referencing lduser.User can still work as long as it is treating the user as an opaque value, and not calling methods on it that were specific to that type.
• All methods that used the type lduser.User now use ldcontext.Context instead.
• lduser.NewUser and lduser.UserBuilder now create an instance of Context instead of User. This is as a convenience so that any code that was previously using these methods to construct a user, but did not reference the User type directly for the result, may still be usable without changes. It is still preferable to use the new constructors and builders for Context.
• The Secondary attribute which existed in User does not exist in Context and is no longer a supported feature.
• 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.
• If you were using JSON serialization to produce a representation of a User, the new type Context uses a different JSON schema, so any code that reads the JSON will need to be adjusted. If you are passing the JSON to other code that uses LaunchDarkly SDKs, make sure you have updated all SDKs to versions that use the new context model. (However, unmarshaling a Context from JSON data will still work correctly even if the JSON is in the old user format.)
• Types such as DataStore, which define the low-level interfaces of LaunchDarkly SDK components and allow implementation of custom components, have been moved out of the interfaces subpackage into a new subsystems subpackage. Some types have been removed by using generics: for instance, the interface type DataSourceFactory has been replaced by ComponentConfigurer[DataSource]. Application code normally does not refer to these types except possibly to hold a value for a configuration property such as Config.DataStore, so this change is likely to only affect configuration-related logic.

Changed (requirements/dependencies/build):

• The minimum Go version is now 1.18.

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 5.x release.
• Removed the Secondary meta-attribute in lduser.User and lduser.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.

[5.10.0] - 2022-07-05

Added:

• ldtestdata.FlagBuilder.VariationForAll and VariationForAllIndex: new names for the deprecated methods listed below.

Changed:

• It was possible to cause analytics event data to be lost by passing ldvalue.Raw(nil) or ldvalue.Raw(json.RawMessage("")) as a default value parameter to JSONVariation, or as the value of a custom user attribute, because a zero-length byte array is not a valid JSON value and would cause the event output to be malformed. The SDK now guards against this by encoding such a value as null in the event data. It is still possible to cause a similar problem by passing a malformed raw value as as ldvalue.Raw(json.RawMessage("{{{")); it is the caller's responsibility not to do so, as the purpose of json.RawMessage is to avoid unnecessary parsing and implies that the value is known to be syntactically valid.

Fixed:

• If a field in Config.ApplicationInfo is set to a string longer than 64 characters, the SDK will now log a warning and discard it, since the LaunchDarkly services cannot process such strings for these fields.
• Prevented a potential data race in LDClient.Initialized(). (#69)

Deprecated:

• ldtestdata.FlagBuilder.VariationForAllUsers and VariationForAllUsersIndex. These methods are being renamed because in the future, there will be other possible kinds of evaluation inputs that are not users, and these test methods will apply equally to those.

[5.9.0] - 2022-03-22

Added:

• Config.ApplicationInfo, for configuration of application metadata that may be used in LaunchDarkly analytics or other product features. This does not affect feature flag evaluations.

[5.8.1] - 2022-01-19

Fixed:

• When using AllFlagsState to produce bootstrap data for the JavaScript SDK, the Go 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.

[5.8.0] - 2022-01-10

Added:

• Config.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 set the ServiceEndpoints property to ldcomponents.RelayProxyEndpoints(myRelayProxyUri) (use RelayProxyEndpointsWithoutEvents instead if your Relay Proxy instance does not have event forwarding enabled).

[5.7.0] - 2022-01-07

Added:

• HTTPConfigurationBuilder.Header allows adding custom HTTP headers to all of the SDK's requests.

Changed:

• The SDK will now log a message at Error level whenever it detects flag data that should not be possible according to LaunchDarkly's validation rules (for instance, a rule that references a nonexistent variation index, or a circular reference in flag prerequisites). Previously, such messages were only logged at Warn level and only if LoggingConfigurationBuilder.LogEvaluationErrors was enabled; that is still the default behavior for other kinds of errors (such as "flag not found"), but malformed data is considered a more serious error because it should not be possible and may require assistance from LaunchDarkly support.

Fixed:

• If the SDK detects a circular reference in flag prerequisites (for example, flag A has flag B as a prerequisite and vice versa), it will now refuse to evaluate the affected flags, returning the default value and an error reason of MALFORMED_FLAG. Previously, such a condition would cause infinite recursion and a stack overflow. LaunchDarkly does not allow circular references to be created in flag configurations, but under rare circumstances an SDK could incorrectly perceive such a state if it received updates out of order; or, the SDK could be configured to use data from a file that contained such references.

[5.6.0] - 2021-08-20

Added:

• Added support for better handling of updates in the Relay Proxy when using big segments. The only API changes for this are in the ldstoreimpl package, which is not meant for regular application use but is used by the Relay Proxy.

Fixed:

• When using big segments, if a big segment store query for a user returned nil, the evaluator was treating that as an automatic exclusion for the user and skipping any rules that might exist in the segment. It should instead treat nil the same as an empty result.

[5.5.0] - 2021-07-20

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.

[5.4.0] - 2021-06-17

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.

[5.3.1] - 2021-06-03

Fixed:

• Fixed a bug in JSON parsing that could cause floating-point numbers (in flag variation values, rule values, or user attributes if a user is being parsed from JSON) to be read incorrectly if the number format included an exponent and did not include a decimal point (for instance, 1e5). Since there are several equally valid number formats in JSON (so 1e5 is exactly equivalent to 100000), whether this bug showed up would depend on the format chosen by whatever software had most recently converted the number to JSON before it was re-read, which is hard to predict, but it would only be likely to happen with either integers that had more than four trailing zeroes or floating-point numbers with leading zeroes.

[5.3.0] - 2021-04-22

Added:

• When using the file data source, ldfiledata.DataSourceBuilder.DuplicateKeysHandling allows you to specify that duplicate flag keys should not cause an error as they normally would.

[5.2.1] - 2021-02-11

Fixed:

• When deserializing feature flags from JSON, an explicit null value for the rollout property (as opposed to just omitting the property) was being treated as an error. The LaunchDarkly service endpoints do not ever send rollout: null, but it should be considered valid if encountered in JSON from some other source.

[5.2.0] - 2021-01-26

Added:

• Added the Alias method to LDClient. This can be used to associate two user objects for analytics purposes with an alias event.

[5.1.4] - 2021-01-21

Fixed:

• Starting in version 5.1.0, an Info-level log message got put: {DATA} was being logged upon making a stream connection, where {DATA} was the JSON representation of all of the feature flag data received from LaunchDarkly. This was unintentional and has been removed.

[5.1.3] - 2021-01-20

Fixed:

• When using semantic version operators, semantic version strings were being rejected by the SDK if they contained a zero digit in any position after the first character of a numeric version component. For instance, 0.1.2 and 1.2.3 were accepted, and 01.2.3 was correctly rejected (leading zeroes for nonzero values are not allowed), but 10.2.3 was incorrectly rejected. This would cause the flag/segment clause to incorrectly return a "match" or "no match" result depending on how the clause was written.

[5.1.2] - 2021-01-11

Fixed:

• If you provide an SDK key that contains an invalid character such as a newline, MakeClient or MakeCustomClient will fail immediately with the error message SDK key contains invalid characters. Previously, it would try to use the invalid key in an HTTP request to LaunchDarkly, and the resulting error message (produced by the Go standard library) would be net/http: invalid header field value [xxx] for key Authorization, where [xxx] was the key you had provided; that could be undesirable if for instance it was a real key that you had accidentally added a newline to, causing the actual SDK key to be visible in the error message in your application log.
• The ldfilewatch package, for using the file data source in auto-update mode, produced some unnecessary and cryptic log messages such as waitForEvents and got close. These have been removed. Instead, the file data source now logs the message Reloading flag data after detecting a change (at Info level) if a file has been updated. (#48)

[5.1.1] - 2021-01-04

Fixed:

• Parsing a User from JSON failed if there was a privateAttributeNames property whose value was null. This has been fixed so that it behaves the same as if the property had a value of [] or if it was not present at all.

[5.1.0] - 2020-12-17

Added:

• The SDK now has an optional integration with the EasyJSON library to increase the efficiency of JSON encoding and decoding. This is enabled if you add the build tag launchdarkly_easyjson to your build (go build -tags launchdarkly_easyjson); no other changes are required. If you do not set the build tag, the SDK does not reference any EasyJSON code.

Changed:

• The SDK's default JSON encoding and decoding logic has been changed to use the new LaunchDarkly library go-jsonstream instead of Go's built-in encoding/json. This should reduce spikes in CPU and memory usage that could occur when the SDK is receiving JSON data from LaunchDarkly or from a database, especially in environments with many feature flags or complex flag configurations. There is also the option to use EasyJSON as described above, but even without that, the new implementation is much more efficient than encoding/json; depending on the size of the data, it can reduce execution time and heap allocations during JSON parsing by roughly 50%.

Fixed:

• Removed an extra newline from the "Reconnecting in..." message that is logged for stream reconnections.

[5.0.2] - 2020-10-20

Fixed:

• When serializing JSON representations for deleted flags and segments, properties with default values (such as false booleans or empty arrays) were being dropped entirely to save bandwidth. However, these representations may be consumed by SDKs other than the Go SDK, and some of the LaunchDarkly SDKs do not tolerate missing properties (PHP in particular), so this has been fixed to remain consistent with the less efficient behavior of Go SDK 4.x. This is very similar to a bug that was fixed in the 5.0.1 release, but it only affects deleted items; we store a placeholder for these (a tombstone) and the JSON for this was being created in a different code path from the one that was fixed.
• The types in go-sdk-common.v2/lduser and go-sdk-common.v2/ldvalue now provide more specific validation errors for JSON unmarshalling, as described in the go-sdk-common 2.0.1 release notes.

[5.0.1] - 2020-10-08

Fixed:

• When serializing flags and segments to JSON, properties with default values (such as false booleans or empty arrays) were being dropped entirely to save bandwidth. However, these representations may be consumed by SDKs other than the Go SDK, and some of the LaunchDarkly SDKs do not tolerate missing properties, so this has been fixed to remain consistent with the less efficient behavior of Go SDK 4.x.