Events are not sent to LaunchDarkly if client is a singleton.

[jeffrey-vang]

Is this a support request? No

Describe the bug Events are not sent to LaunchDarkly if client is not disposed. For long standing applications that register clients as singletons (as recommended, https://docs.launchdarkly.com/sdk/server-side/dotnet) clients are never disposed. This causes events to not be sent to LaunchDarkly unless the Flush method is invoked. However, if the client is injected as a singleton using the ILdClient interface, the Flush method is not available becuase it is apart of the ILdCommonClient interface.

To reproduce

• Register ILdClient as a singleton
• Evaluate a flag
• Check the debugger tab in LaunchDarkly
• No events should appear.
• Flag's last requested date is not updated.

Expected behavior The expected behavior is to see an evaluation event in the debugger tab in LaunchDarkly and the Flag should indicate that it was recently evaluated.

Logs If applicable, add any log output related to your problem.

SDK version 6.3.2

Language version, developer tools For instance, Go 1.11 or Ruby 2.5.3. If you are using a language that requires a separate compiler, such as C, please include the name and version of the compiler too.

OS/platform Windows 10 / OSX

Additional context Add any other context about the problem here.

[eli-darkly]

I'm confused as to whether what you are running here is a typical long-running application, as your description implies ("long standing applications that register clients as singletons")— or something you are launching as a one-shot which then terminates almost immediately. The reason I ask is that events are not only flushed when the client is Disposed; they are also supposed to be automatically flushed at intervals by a worker thread. The default interval is 5 seconds but it is configurable.

I'm not sure why the Flush method was not included in the ILdClient interface (which I assume is what you meant, since there is no such thing as ILdCommonClient in the current SDK)— that may have simply been an oversight— but I'm unclear on what that has to do with the issue you're talking about. If the application is going to exit rapidly without an orderly shutdown of the client, then calling Flush would not help because it is an asynchronous operation.

[jeffrey-vang]

My scenario is running as a long running application. Not as a one shot and terminate the process situation. I think the information I was missing was that they automatically get flushed at 5 second intervals. This appears to be working when using a Web Api. In my case this wasn't happening when I was using the client in a long running main process that doesn't terminate immediately.

[eli-darkly]

This appears to be working when using a Web Api. In my case this wasn't happening when I was using the client in a long running main process that doesn't terminate immediately.

Hmm... I'm still a bit confused, then. I'm not sure what the distinction is that you're making between "a Web Api" and "a long running main process", since normally a webapp or web service is a long-running process.

Can you be more specific about what the differences are between the case where this is working and the case where it isn't working? And, are the differences only in the code, or are these two apps that are hosted in two different environments (in which case the issue might not be "the SDK isn't trying to send events", but rather "something is blocking events from being delivered in this environment")?

Also, is there any log output from the SDK that you can paste here, which might be a clue as to whether it is in fact trying to send events? The bug report form has a "Logs" section which you didn't fill out.

[jeffrey-vang]

This is all done from a local environment so no logs or anything but rather just an observation. If we compare the use of the LdClient in a Web Api vs a console app (that does not terminate rapidly), it appears the events do not get flushed to LD ever.

[eli-darkly]

@jeffrey-vang It should still be possible to get log output when running in a local environment. It's going to be very hard for us to diagnose this problem without more information; that's what the logs are for, otherwise the SDK would just be a black box with no way to say more than "it's not working".

We have many customers using the SDK in ASP.NET-based applications, and analytics events are working for them; our integration testing also includes such applications, and analytics events are being delivered there too. So I think it's safe to say that there is something more specific about your application or your runtime environment than just "it's a Web API" that is making the difference between the SDK working and not working. We would like to figure out what that is, in case there is some kind of subtle compatibility problem, but so far there's not much to go on.

[jeffrey-vang]

@eli-darkly Thanks for the response. I haven't been able to get any log output from the SDK to actually see whats going on but I think for the majority of use cases of this SDK everything is working as expected. I think what I am experiencing is just a misunderstanding of how this SDK is intended to be used and that this issue can be closed.

[eli-darkly]

Well, to be clear, having the SDK client be maintained as a singleton is definitely a use case that is supposed to work; you didn't misunderstand anything in that regard.

If you'd like us to look further into this, one way to go would be to open a support ticket at support.launchdarkly.com (so that we have a more secure communication channel), tell them it's a follow-up to this issue & that I said to contact me, and send the parts of your code that deal with configuration.

Also, regarding the logging— it would definitely be useful to get the log output working, but logging in ASP.NET can be a bit weird and is heavily dependent on the hosting environment, so it's hard for me to know exactly what will work for you. If it's an ASP.NET Core application, then probably what you want is to add this. Or, if you're using Log4Net, this.

[kinyoklion]

Closing this because there has not been any recent activity. If there are any follow up question, then please file those as new issues.

Generally summary of events configuration for anyone who happens upon this: The SDK should flush events on an interval, and that interval is configurable. Web based SDKs flush much more frequently because the opportunity for losing events is higher than a server SDK.

Events can also manually be flushed. In the case of this SDK disposing the client will also flush events.