Launch Darkly client not initializing

[davidryee]

I followed the set up instructions as follows:

@client = LaunchDarkly::LDClient.new(<sdk_key>)
hash = Hash.new
@client.variation('flag_name', hash, false)

However, I keep getting an error stating [LDClient] Client has not finished initializing; feature store unavailable, returning default value

I'm noticing that @data_source.initialized? is false in this statement:
@config.offline? || @config.use_ldd? || @data_source.initialized? at this line in ldclient.rb

I also noticed that @initialized.make_true is never called at this line in stream.rb

The code that is ingesting the ruby-server-sdk is in a library used by another application that may already have its own launch darkly ruby-server-sdk as well.

Does anyone know why the LD Client is not being initialized? Thank you!

[eli-darkly]

This is a very general problem report that amounts to "something didn't work"— there's nothing obviously wrong with the first line of your code example, so it's possible that something else is going on with your runtime environment, in which case you might have better luck filing a support request at support.launchdarkly.com. But I can make some very general guesses at least.

Were any other log messages produced by the SDK before the "[LDClient] Client has not finished initializing" message? And is there a noticeable delay? Normally, what that message would indicate is that the SDK had already been trying and failing to connect to LaunchDarkly for 5 seconds (that being the default value of the wait_for_sec parameter to LDClient.new), which I would expect to have produced some output. It would not be normal for LDClient.new to return immediately if initialization had not finished.

[davidryee]

Were any other log messages produced by the SDK before the "[LDClient] Client has not finished initializing" message? And is there a noticeable delay? Normally, that message would indicate is that the SDK had already been trying and failing to connect to LaunchDarkly for 5 seconds (that being the default value of the wait_for_sec parameter to LDClient.new), which I would expect to have produced some output. It would not be normal for LDClient.new to return immediately if initialization had not finished.

Thank you for getting back to me. The SDK reported the following:
[LDClient] Initializing stream connection
[LDClient] sending diagnostic event: {"kind":"diagnostic-init"....
Connecting to event stream at https://stream.launchdarkly.com/all // waited for ~5 seconds
[LDClient] Timeout encountered waiting for LaunchDarkly client initialization
[LDClient] Client has not finished initializing; feature store unavailable, returning default value

The app that ingests my library was able to connect with the same sdk key before my library tried to connect.

Also, I see that the @data_source variable is not initialized when I inspect this line

[eli-darkly]

It looks to me like possibly a network issue, or something in your environment interfering with network connections; I don't see any reason to think it is an SDK bug. If you really didn't change anything about your environment from the original test case when it worked correctly, other than moving the LD-related code into a library, that is certainly odd. But I can't really diagnose it any further just based on this. Here's all I can say:

The SDK's initialization logic goes like this: 1. Try to make an HTTP connection to stream.launchdarkly.com, providing the SDK key in an Authorization header. 2a. If a connection is made, wait for the server to send the flag data. 2b. If the connection attempt failed with an I/O error (like "host not found"), or if the server responded with an HTTP error like 503 (as opposed to 401 which would mean the SDK key is bad), log the problem and try again from step 1. It will keep retrying that connection as long as it takes, on a worker thread, even if the 5-second timeout forces LDClient.new to return early. But, since no connection errors or HTTP errors were logged, I can infer that either the connection attempt is hanging (which could be caused by a network problem), or, it is successfully connecting but then it is hanging waiting for flag data (which could be a LD service issue, but it's more likely to be a network problem because we haven't seen any sign of problems with this service).

None of that should have been affected by simply moving your code into a library, so again I am wondering if that was really the only change, or if there could be anything else different in terms of your runtime environment as compared to earlier when it was working. But in any case, the behavior you are seeing is what would happen if the initial request to LD hangs, so I would suggest investigating this the same way you would for any hanging request to an external service that is known to be working for other users. For instance, if on the same machine where your code is running, you make a direct request like curl -H 'Authorization:YOUR_SDK_KEY' https://stream.launchdarkly.com/all, do you see data.

[davidryee]

Thank you for the insight. I am able to see data with the curl request.

I experimented with my setup which is a Rails application that ingests a library as a gem. When both the Rails application and the library instantiate their own Launch Darkly clients(LaunchDarkly::LDClient.new(<sdk_key>)), the library's gives the error stating "[LDClient] Client has not finished initializing; feature store unavailable, returning default value"

However, when I inject the Rails application's LaunchDarklyClient object into the library, I do not get the error. Everything behaves correctly. Could it be that having 2 separate Launch Darkly clients in the same process/application is causing this error? Is this usage not allowed?

Thank you!

[eli-darkly]

Having two client instances in the same process is allowed. The SDK doesn't have any state in global variables, everything is scoped to an LDClient instance, so I'm not sure how one could be interfering with the other.

[eli-darkly]

But I also can't think of why things would behave differently when used from your gem instead of from your application, so either way, there is a mystery here.

[jacobbeasley]

I see this has not been updated in some time. Can this be closed out?

[keelerm84]

As we have not heard any additional reports from this customer or others of the SDK not initializing, I am going to close this issue out.

[jacobbeasley]

We actually reported this issue to you last week (see ticket submitted by Ascend Learning)

[ideaoforder]

I'm still having this issue. Same circumstance--two Rails apps running locally. I'm guessing this isn't fixed, there just haven't been accounts using a similar setup in some months.

[jacobbeasley]

Yeah, we ended up just switching back to rolling this ourselves. The performance was too poor to use. It had 4x'ed our CPU usage in production.

[rselk]

I work with @ideaoforder who posted above. For our specific issue, the problem was the https://github.com/trusche/httplog gem. Adding launchdarkly to the httplog blacklist fixed the issue.

[zshen-figma]

hi @rselk could you elaborate a bit more, how does this related to httplog?