This repository was archived by the owner on May 30, 2024. It is now read-only.
Releases: launchdarkly/node-server-sdk
Releases · launchdarkly/node-server-sdk
5.14.4
[5.14.4] - 2021-04-29
Fixed:
- Updated the minimum compatible version of the
redispackage dependency to3.1.1to ensure the resolution of CVE-2021-29469 in customers' environments.
5.14.3
[5.14.3] - 2021-04-01
Fixed:
- The property
LDOptions.inlineUsersInEventswas not included in the TypeScript definitions.
5.14.2
[5.14.2] - 2021-02-11
Fixed:
- Fixed an issue where "feature" and "custom" events were not properly indicated as being triggered by anonymous users. This bug affected customers who were using this functionality, which was introduced in version 5.14.0, when correlating users with LaunchDarkly's data export add-on.
5.14.1
5.14.0
[5.14.0] - 2021-01-29
Added:
- Added the
aliasmethod toLDClient. This can be used to associate two user objects for analytics purposes with an alias event.
5.13.5
[5.13.5] - 2021-01-25
Changed:
- In streaming mode, the SDK now automatically drops and restarts the stream connection if it has received no data from the server within a 5-minute interval. This ensures that if the connection fails in such a way that the SDK cannot detect the failure as an I/O error, it will not hang forever waiting for updates from the phantom connection. The LaunchDarkly streaming service sends a tiny "heartbeat" message at regular intervals less than this timeout, to ensure that the SDK will not drop the connection if it is still usable. This logic exists in most other LaunchDarkly SDKs but was not previously implemented in the Node server-side SDK.
5.13.4
[5.13.4] - 2020-08-27
Fixed:
- When using the Redis integration without trying to connect to LaunchDarkly (such as when using the Relay Proxy with Redis in "daemon mode"), a flag evaluation that was done immediately after initializing the SDK client could fail due to the Redis client not having time to make its connection to Redis. This has been fixed so that it will wait for the connection to be established. This was never an issue when not using daemon mode, because if the SDK did connect to LaunchDarkly then it would proceed to store the flags in Redis and would not finish initializing until it had done so. (#193)
5.13.3
[5.13.3] - 2020-06-30
Fixed:
- A bug introduced in 5.13.2 caused the output of the default logger to be formatted incorrectly.
5.13.2
[5.13.2] - 2020-06-30
Changed:
- The default implementation of logging now uses Winston 3.x rather than Winston 2.x. This does not change the content of the log output, and if you have specified your own custom logger then the SDK still uses that. The only effect is that the SDK no longer has dependencies on Winston 2.x. (Thanks, FauxFaux!)
Fixed:
- Previously, calling
LDClient.waitForInitialization()multiple times before the client had finished initializing would create a new Promise, and a new event listener, each time. This could cause unwanted overhead and possibly trigger warnings about too many event listeners. Now,waitForInitialization()will always return the same Promise instance and will not create multiple listeners. - Fixed a bug that could cause extra delays when receiving a large streaming update. The process will still be blocked for some amount of time as the JSON data is being parsed, which is unavoidable in the current architecture, but this bug made it block for longer than necessary.
- Improved and clarified Typedoc documentation for several types and methods.
5.13.1
[5.13.1] - 2020-04-24
Changed:
- The
redispackage dependency has been updated to major version 3, which removes some deprecated usages (see #184) and adds support forrediss:URLs. This should not affect any application code even if the application is passing in a pre-built Redis client that was created with version 2.x, since the Redis methods that are used by the SDK have not changed.
Fixed:
- If a proxy server was specified in the configuration, streaming connections still did not use the proxy. This bug was introduced in version 5.12.0. (#186)
- The SDK could cause a crash if the application provided a configuration where
loggerwas either not a logger at all (that is, some other object that did not have the methods defined in theLDLoggerinterface), or was a broken logger that could throw an exception while the SDK was trying to log an error. The former case (not a logger) is now treated as a severely invalid configuration, causingLDClient.init()to throw an exception just as it would if the SDK key were omitted. The latter (logger method throws an exception) is now handled by catching the exception and logging an error message to the default console logger. (Thanks, maxwellgerber!) - The Redis integration no longer calls
unref()on the Redis client object after creating it. This was originally done to ensure that the SDK client would not prevent an application from exiting due to a still-open Redis connection, but that is no longer applicable since the application must close the SDK client anyway before exiting, which will cause the Redis client to be closed as well. Theunref()call caused problems when running in Lambda, for unclear reasons. (#76)