[kinyoklion]

InitializeAsync ignored its CancellationToken, so a caller that passed a token to SetProviderAsync could not stop waiting for the LaunchDarkly client.

• Cancelling the token now completes InitializeAsync with an OperationCanceledException instead of waiting for the data source
• Cancellation is per-call: cancelling one wait leaves the provider initializing and does not fail other waiters
• Feature matrix Initialization row updated to describe the behavior

Requirements

• I have added test coverage for new or changed functionality
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Related issues

None.

Implementation details

The OpenFeature .NET SDK passes the token given to Api.SetProviderAsync(provider, cancellationToken) through ProviderRepository into FeatureProvider.InitializeAsync. The provider returned _initCompletion.Task directly, so the token had no effect.

Waiting now goes through a helper which, when the token can be canceled, races _initCompletion.Task against a TaskCompletionSource canceled by a token registration. _initCompletion itself is untouched, so the provider still becomes READY (or errors) when the data source reports its state, regardless of a canceled wait.

Shutdown is unchanged: it only removes listeners and disposes the client, so there is no wait to cancel.

Tests: two cases covering cancellation of a first wait and of a wait on an already in-progress initialization. dotnet test -f net8.0 passes (70 tests).

Note: #71 also changes initialization waiting; whichever merges second needs a trivial rebase of this region.

Link to Devin session: https://app.devin.ai/sessions/a47abf28ecd44130917b9b5131287221
Open in Devin Desktop: https://app.devin.ai/desktop/session/a47abf28ecd44130917b9b5131287221?variant=devin
Requested by: @kinyoklion

SDK-3255

---

Note

Overview
InitializeAsync now honors the CancellationToken passed through OpenFeature (e.g. from SetProviderAsync), so callers can stop waiting for the LaunchDarkly data source without blocking until ready or permanent failure.

Waiting goes through WaitForInitializationAsync, which races _initCompletion against token cancellation. Cancellation is per call: _initCompletion is unchanged, so the client can still finish initializing and other waiters are unaffected. A canceled wait completes with OperationCanceledException.

StatusProvider gains StartupWaitCanceled: it clears the “first event” suppression and, if status is already known, emits the matching provider event so subscribers still see READY (or stale/error) after a canceled startup wait. Status messages are retained for that replay; event emission is centralized in EmitStatusEvent.

The README Initialization row and three unit tests document and cover token cancel on first wait, cancel on a concurrent second wait, and ProviderReady after cancel when the data source later becomes valid.

^{Reviewed by Cursor Bugbot for commit afef99f. Bugbot is set up for automated code reviews on this repo. Configure here.}

[devin-ai-integration]

I'll fix CI failures and address comments from users with write access. I'll skip comments containing "(aside)".

• Disable automatic comment, CI, and merge conflict monitoring

[devin-ai-integration]

@cursor review

[cursor]

Stale Bugbot comment from a previous run.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit fb037c7. Configure here.}