Option to not call add_event/3 or disable event tracking all together.

[rparcus]

Is your feature request related to a problem? Please describe.
Using LaunchDarkly in certain code paths that are deep in the call stack can easily starve the events buffer and the events processor. Not to mention that when millions of events get dropped, millions of warning messages get logged, which can also be problematic.

What are the plans to support optionally not calling add_event/3 when evaluating flags?

I'd be available to create a pull request but would be glad to hear some input from you on how it should would ideally look like.

Describe the solution you'd like
Quick fix: Add the ability to pass options to variation/3 and variation_detail/3, so that we could skip adding events to the buffer.
Ideal fix: Something similar to what the go client provides, where we can initiate a client with disabled events or temporarily disable them when they are enabled.

[bwoskow-ld]

Hi @rparcus,

Thanks for the feedback!

As you point out, at the moment there is no programmatic mechanism for conditionally turning off events sending. If your application is redundantly evaluating feature flags (multiple evaluations with the same key and user context) multiple times in a call stack, we recommend that you modify your code so that the flag is evaluated just once at an early part of the stack and then the resulting variation value is passed along as appropriate. There are several benefits of doing this. The most obvious benefit is that you will generate far fewer events, hopefully enough that you would no longer encounter the starvation issue you're seeing. Secondly, flag metrics will more accurately reflect real usage instead of being weighted towards requests which have more invocations. Thirdly, you'll avoid a situation where a user would conditionally see different variations for a single call -- if you happened to change your flag definition in the middle of the call stack.

However, sometimes this might not be feasible or maybe your variation calls are not redundant. In this case we'd want to have something in line with the events disablement decorator that you linked in our Go SDK. I filed an internal feature request for this just now however it is not currently a priority -- if you have the bandwidth and desire to create a pull request, we would appreciate it!

Cheers,
@bwoskow-ld

Filed internally as 109310.

[Dayreea]

_)

[kinyoklion]

We've decided that we are not currently going to support this. Events are fundamental to the operation of many functions of LaunchDarkly (experimentation being one of the foremost).

We are working on some features that could allow clients with very selective flags, and then use a client instance with events disabled that only has access to those flags.

Thank you,
Ryan