Launchdarkly-server-sdk

Latest version: v9.4.0

Safety actively analyzes 638730 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 6 of 15

6.13.1

Fixed:
- A problem with the SDK&39;s use of `urllib3.Retry` could prevent analytics event delivery from being retried after a network error or server error. ([143](https://github.com/launchdarkly/python-server-sdk/issues/143))

6.13.0

Added:
- The new `Config` parameter `initial_reconnect_delay` allows customizing of the base retry delay for stream connections (that is, the delay for the first reconnection after a failure; subsequent retries use an exponential backoff).
- The new `Config` parameter `http` and the `HTTPConfig` class allow advanced configuration of the SDK&39;s network behavior, such as specifying a custom certificate authority for connecting to a proxy/gateway that uses a self-signed certificate.

Changed:
- The retry delay for stream connections has been changed as follows: it uses an exponential backoff no matter what type of error occurred (previously, some kinds of errors had a hard-coded 1-second delay), and each delay is reduced by a random jitter of 0-50% rather than 0-100%. Also, if a connection remains active for at least 60 seconds, the backoff is reset to the initial value. This makes the Python SDK&39;s behavior consistent with other LaunchDarkly SDKs.

Deprecated:
- The existing `Config` properties `connect_timeout`, `read_timeout`, and `verify_ssl` are now deprecated and superseded by the equivalent properties in `HTTPConfig`.

6.12.2

Fixed:
- Setting `verify_ssl` to `False` in the client configuration did not have the expected effect of completely turning off SSL/TLS verification, because it still left _certificate_ verification in effect, so it would allow a totally insecure connection but reject a secure connection whose certificate had an unknown CA. This has been changed so that it will turn off certificate verification as well. _This is not a recommended practice_ and a future version of the SDK will add a way to specify a custom certificate authority instead (to support, for instance, using the Relay Proxy with a self-signed certificate).

6.12.1

Not secure
Fixed:
- When diagnostic events are enabled (as they are by default), the SDK was logging spurious warning messages saying "Unhandled exception in event processor. Diagnostic event was not sent. [&39;DiagnosticEventSendTask&39; object has no attribute &39;_response_fn&39;]". The events were still being sent; the misleading message has been removed.

6.12.0

Not secure
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 Python 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 `diagnostic_opt_out` option or configured with `diagnostic_recording_interval`.

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.

6.11.3

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

Page 6 of 15

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.