.waitForInitialization() hangs

[sirthomasbayes]

The call: const client = await LaunchDarkly.init('API-KEY').waitForInitialization(); never returns.

ldclient-node version 5.6.2

[eli-darkly]

Can you give me any more details at all, such as whether the client is logging anything?

(I presume that you've ruled out the possibility of an exception being thrown on that line. The promise returned by waitForInitialization() resolves if the client starts up successfully, but if there's an error then it'll be rejected, which would cause an exception from await.)

[sirthomasbayes]

Yes, I've ruled out the possibility of an exception being thrown. Currently, the client isn't logging anything.

[eli-darkly]

The lack of any log output is odd. Unless you've configured the client to be in offline mode (which, in your example, you haven't), I would expect the init function to always log the message "Initializing stream processor to receive feature flag updates"— that should happen before it even gets to waitForInitialization().

[sirthomasbayes]

Ah my mistake, should have been more specific. It does log the initialization message, but afterwards there are no logs.

[sirthomasbayes]

think I found the issue.

In eventsource.js , for some reason the listeners are never being invoked. (I'm receiving events for open and put, but self.listeners(arguments[0]).length === 0 for both events)

function _emit() {
    // conditional evaluates to false
    if (self.listeners(arguments[0]).length > 0) {
      self.emit.apply(self, arguments);
    }
  }

[sirthomasbayes]

Removed the conditional just as a quick test, and was able to get the client to return successfully from .waitForInitialization() .

[eli-darkly]

Hmm. We're running this version of the Node SDK ourselves and if event listeners were not firing, it wouldn't be able to start up. What version of Node are you using?

[sirthomasbayes]

I'm currently running Node v10.14.1

[eli-darkly]

I'm sorry so much time passed without an update, but basically I haven't had any luck reproducing this— not with the specific versions of Node and of the SDK that you mentioned, and not with any other versions. The streaming/EventSource code is working as usual for me... and it's hard to see how the behavior you detected is even possible, since streaming.js calls addEventListener to add all of its listeners immediately after creating the EventSource. I believe you that it's somehow not seeing the listeners, but I can't think how.

[sahilsarpal1]

@eli-darkly Happening to me also, in my case when my redis server is down. launch darkly sdk is not throwing any exception or response to me, In my node logs it is trying to reconnect again and again. This is making my application to stop.

Below attached is the screenshot of my error logs. Please check.

[eli-darkly]

@sahilsarpal1 I believe that is not the same issue. When the SDK first starts up and establishes a connection to LaunchDarkly, it receives all of your flag data, and it immediately tries to write that data to the feature store. If the feature store is Redis, and Redis is down, then this will fail and it will consider initialization to have failed; it attempts to restart the stream connection in this case in order to ensure that it will get a fresh set of flags for the next attempt to put them in Redis.

This is basically how the Redis integration works in all of the server-side SDKs: if Redis is down, it will not proceed with just an in-memory flag cache, instead it will consider the SDK to be in an invalid state. We have considered some changes to this behavior, but currently that is the expected behavior. It is not what the original reporter described in this issue.

[sahilsarpal1]

@eli-darkly Yes you are true, this is not the reported issue, but I thought It is kinda similar, thats why i thought you guys could help me with my scenerio.

Actually I was integrating Launch Darkly to my project and generating all possible scenario, to avoid any kind of functional problem in the future. I got stuck with is one last scenario, of which I m looking some answers to solve this one, I hope you are the right person to address the problem.

The problem which I am facing is:- Let suppose some how my LD sdk failed to make connection with redis. (due to my redis server failure or anything else). I didn't get any exception so that I could handle that exception, and continue with an alternative approach. This behavior is making my application stuck.

How could i handle this scenerio ?

[eli-darkly]

@sahilsarpal1 In the current Node SDK architecture, there is no way to detect that condition. The best you could do would be to enforce a timeout for initialization (there is no timeout mechanism built into the SDK but as with any async operation, you can always create a timer and then see which of the two callbacks/promises fires first). That is probably preferable anyway, because from the point of view of your application it doesn't really matter whether initialization is not succeeding due to Redis not being available, or for some other reason (i.e. lack of network connectivity)— in either case you will have the same problem, flags not being available, so you probably would want to treat them the same.

[HistoricallyCorrect]

This is making my application to stop.

I think we are experiencing the same issue, the difference is I don't use redis the same way and I can reproduce the error by disconnecting my wifi.

I posted my findings here. https://github.com/launchdarkly/node-server-sdk/issues/155#issuecomment-540882178

[eli-darkly]

@HistoricallyCorrect I don't see why you're saying that that is the same issue. You are reporting getting an error which caused your application to get an unhandled promise rejection (because you didn't have an error handler). This issue from sirthomasbayes is about the application hanging with no error, not crashing, not having an uncaught error thrown. I'll follow up on your comment on the other issue, but wanted to avoid muddying the waters on this one because they really do not seem related.

[HistoricallyCorrect]

@eli-darkly replied in the other issue.

[eli-darkly]

Closing this issue due to inactivity.