Affected: Server-side SDKs
Symptoms
After applications using LaunchDarkly server-side SDKs exit or restart, you may notice:
- Orphaned streaming connections that do not close properly
- Bottlenecks caused by unclosed SDK instances
- Lost analytics events, particularly in serverless or short-lived processes
- Gradual memory leaks over time in long-running applications
Cause
By default, LaunchDarkly SDKs maintain a persistent connection to receive real-time flag updates. In environments where the application lifecycle is short or involves forking processes, failing to shut down the SDK explicitly can cause stale connections, incomplete event dispatching, or memory/resource leaks.
Solution
To prevent lingering connections or lost events, ensure that your application calls close() on the SDK client when appropriate. Use the following guidance based on your architecture:
For serverless functions (such as AWS Lambda):
These environments are ephemeral and do not maintain persistent connections.
- Add a Lambda extension or shutdown hook that calls
close()at the end of the function execution. - This ensures all analytics events are sent before the function exits.
In forked processes (such as Django or Rails workers):
Forked child processes do not inherit connections cleanly.
- After the child process completes its work, call
close()on the SDK instance to avoid stale connections. - This is especially important in background jobs or queue workers.
During testing or mocking SDK usage:
Unit or integration tests may create real SDK instances unnecessarily.
- Use the LaunchDarkly CLI testing tools where possible.
- If you must instantiate a real SDK client, call
close()at the end of each test case or suite to clean up connections.