5.13.0

[5.13.0] - 2020-04-07

Added:

• Configuration option streamInitialReconnectDelay, which is the same as the recently-added streamInitialReconnectDelayMillis but measured in seconds instead of milliseconds; this makes it consistent with how durations are represented in other options.

Deprecated:

• Configuration option streamInitialReconnectDelayMillis.

5.12.0

[5.12.0] - 2020-04-03

Added:

• New configuration option streamInitialReconnectDelayMillis allows setting the initial delay (not including jitter) for stream reconnections.

Changed:

The stream reconnection behavior has been changed to be consistent with other LaunchDarkly SDKs, as follows:

• Previously, there was a fixed delay of 125 milliseconds for the first attempt to reconnect after a stream failure, which would then increase with an exponential backoff for subsbequent retries up to a maximum of 15 seconds (but the backoff was used only after HTTP error responses, not connection failures).
• Now, the delay starts at 1000 milliseconds, unless changed with streamInitialReconnectDelayMillis.
• The new maximum is 30 seconds.
• The backoff now applies to all types of stream failures.
• There is now a jitter that randomly reduces each delay by up to 50%.
• The delay now resets to the initial level if the stream has been active for at least 60 seconds.

5.11.3

[5.11.3] - 2020-03-09

Changed:

• The SDK no longer has dependencies on the deprecated request package and request-etag. Instead it uses the Node HTTP API directly.

Fixed:

• Fixed a bug that, in polling mode, could cause polls to fail with the error "Cannot read property 'data' of undefined" if the network became unavailable on the previous poll attempt but then became available again.

5.11.2

[5.11.2] - 2020-02-20

Changed:

• Updated the request package dependency due to a vulnerability warning, even though the SDK was not using the functionality described in that warning.

5.11.1

[5.11.1] - 2020-02-13

Fixed:

• When sending stream connection statistics in diagnostic event data, always specify the failed property even if it is false. This only affects LaunchDarkly's internal analytics.

5.11.0

[5.11.0] - 2020-02-12

Note: if you are using the LaunchDarkly Relay Proxy to forward events, update the Relay to version 5.10.0 or later before updating to this Node SDK version.

Added:

• The SDK now periodically sends diagnostic data to LaunchDarkly, describing the version and configuration of the SDK, the architecture and version of the runtime platform, and performance statistics. No credentials, hostnames, or other identifiable values are included. This behavior can be disabled with the diagnosticOptOut option, or configured with diagnosticRecordingInterval.

Fixed:

• Setting the inlineUsersInEvents option caused a spurious warning message saying it was an unknown option. This did not prevent it from working.
• Updated comment on init to clarify the intended singleton usage pattern.

Removed:

• Removed an unnecessary dependency on the package node-sha1. (#173)

5.10.3

[5.10.3] - 2020-01-15

Fixed:

• The SDK now specifies a uniquely identifiable request header when sending events to LaunchDarkly to ensure that events are only processed once, even if the SDK sends them two times due to a failed initial attempt.

5.10.2

[5.10.2] - 2020-01-13

Fixed:

• The implementation of the RedisFeatureStore function was inconsistent with its TypeScript declaration: instead of taking client as an optional parameter, it was looking for it as a property within redisOpts. It now correctly supports the optional parameter; passing the property in redisOpts is still supported for backward compatibility, but is deprecated (since it is not a valid property of that object type) and will be removed in a future version.

5.10.1

[5.10.1] - 2020-01-06

Fixed:

• In rare circumstances (depending on the exact data in the flag configuration, the flag's salt value, and the user properties), a percentage rollout could fail and return a default value, logging the error "Data inconsistency in feature flag ... variation/rollout object with no variation or rollout". This would happen if the user's hashed value fell exactly at the end of the last "bucket" (the last variation defined in the rollout). This has been fixed so that the user will get the last variation.

5.10.0

[5.10.0] - 2019-12-11

Added:

• RedisFeatureStore now accepts an optional client parameter, if you have an existing RedisClient instance that you want to reuse.

Changed:

• The SDK now logs a warning if any configuration property has an inappropriate type, such as baseUri:3 or offline:"yes". For boolean properties, the SDK will still interpret the value in terms of truthiness, which was the previous behavior. For all other types, since there's no such commonly accepted way to coerce the type, it will fall back to the default setting for that property; previously, the behavior was undefined but most such mistakes would have caused the SDK to throw an exception at some later point.