Use StartWaitTime from configuration as provider blocking initialization timeout

[Alex-Tseshinskii]

Is your feature request related to a problem? Please describe.
If LaunchDarkly is transiently unavailable at provider initialization (that happens during OpenFeature.Api.Instance.SetProviderAsync(provider); call), provider initialization does not end (task is not being completed) until the transient problem is resolved.

So, if an application waits for LaunchDarkly initialization as in your basic example here
https://github.com/launchdarkly/openfeature-dotnet-server?tab=readme-ov-file#usage

it will not start until LaunchDarkly host is available

Describe the solution you'd like
I would like that Provider class was taking into the account StartWaitTime configuration value it receives with configuration from the constructor call and returned the control to awaiting execution flow after StartWaitTime has passed

var config = Configuration.Builder("my-sdk-key")
    .StartWaitTime(TimeSpan.FromSeconds(10))
    .Build();

var provider = new Provider(config);

Describe alternatives you've considered
An alternative solution we're using now looks like that

    private readonly Api _featureApi;
    private readonly LaunchDarklyOptions _options;
...
        try {
            await _featureApi.SetProviderAsync(service).WaitAsync(_options.StartWaitTime, cancellationToken);
        }
        catch (TimeoutException) {
// Log unavailability on startup
        }

It looks more like a hack than a clean and neat solution

Additional context
The issue arose during last LaunchDarkly problems induced by AWS unavailability. LaunchDarkly answered with 4XX/5XX codes for about 6 hours, and for Provider class internally that was a "recoverable" problem. So to start our application we had to mock OpenFeature completely out of production version, because our application just couldn't start, waiting for LaunchDarkly connection indefinitely

[kinyoklion]

Hello @Alex-Tseshinskii,

I think in the short-term the correct answer is just to use a timeout on the await.

I think all you need is, but I will need to test it first in the example.
https://learn.microsoft.com/en-in/dotnet/api/system.threading.tasks.task.waitasync?view=net-6.0#system-threading-tasks-task-waitasync(system-timespan)

try {
    await OpenFeature.Api.Instance.SetProviderAsync(provider).WaitAsync(TimeSpan.FromSeconds(10));
} catch(TimeoutException) {
 // Initialization timed out, note and move on.
}

We will have to ponder on the semantics of the timeout interaction with the provider state and events. Because it feels like this kind of timeout is something that should be at the OpenFeature level.

Thank you,
Ryan

Filed internally as SDK-1518

[Alex-Tseshinskii]

Sorry, I was not quite clear in my code - that's exactly what we did now. That's true, it works

[kinyoklion]

Sorry, I was not quite clear in my code - that's exactly what we did now. That's true, it works

Ah, sorry, I see you did list it in the alternatives. Sorry about that.

I do think it is the correct answer for the time being. I have some hesitation in making the semantics of registering a provider effectively be different for the LD SDK. But it may be a good idea to move the idea of a timeout to the OpenFeature dotnet SDK.

Thank you,
Ryan

[kinyoklion]

I think we could potentially transition to a provider error state and then continue to attempt to recover. The problem isn't so much the timeout itself as how it affects the state via the state events and accessing provider state. For the LD SDK not having initialized itself isn't an error state, it is basically independent.