Go SDK
Mon
Wed
Fri
JunJulAugSepOctNovDecJanFebMarAprMayJun
LessMore
Releases16Avg5/moVersionsv7.15.4
Last Checked
4h ago
All notable changes to the LaunchDarkly Go SDK will be documented in this file. This project adheres to Semantic Versioning.
ChangeSet.Collections to help reduce relay memory usage (#332) (ca33a3c)This release introduces the ability to enable compression of event payloads. When enabled, the SDK will compress events before sending them to the LaunchDarkly servers. This can reduce the bandwidth required to send events, which can be useful in high-traffic environments to reduce egress traffic costs.
Important
Relay Proxy users MUST upgrade to version 8.9 or higher prior to enabling this option to prevent loss of event data.
However, enabling this feature is NOT required when using the Relay Proxy as it will manage compression automatically.
This release contains no functional changes. It is a product of structural changes to the repository.
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.
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.
Migrator type which provides an out-of-the-box configurable migration framework.MigrationVariation and TrackMigrationOp methods on LDClient.LDClientEvaluations interface now has a MigrationVariation method.LDClientEvents interface now has TrackMigrationOp method.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.
go-sdk-common, the new package ldcontext with the types Context and Kind defines the new context model.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().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.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.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.Secondary attribute which existed in User does not exist in Context and is no longer a supported feature.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.)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.Secondary meta-attribute in lduser.User and lduser.UserBuilder.Alias method no longer exists because alias events are not needed in the new context model.InlineUsersInEvents option no longer exists because it is not relevant in the new context model.ldtestdata.FlagBuilder.VariationForAll and VariationForAllIndex: new names for the deprecated methods listed below.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.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.LDClient.Initialized(). (#69)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.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.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.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).HTTPConfigurationBuilder.Header allows adding custom HTTP headers to all of the SDK's requests.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.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.ldstoreimpl package, which is not meant for regular application use but is used by the Relay Proxy.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.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.ldfiledata.DataSourceBuilder.DuplicateKeysHandling allows you to specify that duplicate flag keys should not cause an error as they normally would.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.Alias method to LDClient. This can be used to associate two user objects for analytics purposes with an alias event.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.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.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.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)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.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.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%.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.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 Go 4.x to 5.0 migration guide for an in-depth look at the changes in this version; the following is a summary.
LDClient.GetFlagTracker().LDClient.GetDataSourceStatusProvider(). This allows you to check the current connection status, and to be notified if this status changes.LDClient.GetDataStoreStatusProvider(). This allows you to check whether database updates are succeeding, to be notified if this status changes, and to get caching statistics.LDClient.WithEventsDisabled() is a decorator that allows you to temporarily turn off analytics events even if events are enabled in your configuration.LDConfig.Logging is a new configuration category for options related to logging. See ldcomponents.Logging() and ldcomponents.NoLogging().testhelpers/ldtestdata package provides an alternative to ldfiledata for simulating feature flag data in test code.AllFlagsState() can now be constructed (such as for testing purposes) with flagstate.NewAllFlagsBuilder().interfaces, LDClientInterface, LDClientEvaluations, and LDClientEvents are new interfaces describing the existing methods of LDClient. These may be useful for creating mocks in testing.