Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

2nd call to set_config reopens the client without reopening the streaming connection #218

Closed
tsiq-clemens opened this issue Aug 30, 2023 · 2 comments
Labels
Stale waiting for feedback Indicates LaunchDarkly is waiting for customer feedback before issue is closed due to staleness.

Comments

@tsiq-clemens
Copy link

tsiq-clemens commented Aug 30, 2023

Describe the bug
In our code, we accidentally called a code segment twice when our web service initiates, which effectively calls set_config() twice.

ldclient.set_config(Config(config.sdk_key))
self.ldclient = ldclient.get()

What happens is that set_config() notices that a client already exists, so it prints "reinitializing", then closes the client and opens another. However, no updates to any LD flags make it to the client, it seems like there is no longer a streaming connection.

Our fix was to not run the segment above 2x, and then any updates from the LD UI make it to the server as expected.
I am aware that one should not call set_config twice, but when you do so (accidentally) its behavior is at best confusing as a client exists and works but gets no live updates anymore.

To reproduce
Call set_config() twice, followed by the singleton .get(); make a change to a flag in the LD UI and validate that the client is not aware of it.

Expected behavior
set_config() closes an existing client and opens another. I would expect the new client to reopen/maintain the streaming updates to the LD server.

SDK version
7.6.1

Language version, developer tools
python 3.9

OS/platform
Linux

@keelerm84
Copy link
Member

Thank you for reporting this issue.

I did a quick test using the hello python project, and when I call set_config twice, subsequent interactions with the client seem to receive updates as expected.

Is it possible you are retaining a reference to the client created after the first call to set_config? I believe that would mimic the behavior you are seeing if that were the case.

LaunchDarklyReleaseBot pushed a commit that referenced this issue Sep 6, 2023
When using the test data source, the trackEvents may not be required.
Additionally, when receiving this information from LD, there is no
guarantee that field will be provided. Instead of assuming that field
always exists on the flag model, we should instead retrieve it with a
default value to prevent index errors.
@keelerm84 keelerm84 added the waiting for feedback Indicates LaunchDarkly is waiting for customer feedback before issue is closed due to staleness. label Sep 6, 2023
@github-actions
Copy link
Contributor

github-actions bot commented Oct 7, 2023

This issue is marked as stale because it has been open for 30 days without activity. Remove the stale label or comment, or this will be closed in 7 days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Stale waiting for feedback Indicates LaunchDarkly is waiting for customer feedback before issue is closed due to staleness.
Projects
None yet
Development

No branches or pull requests

2 participants