feat!: Add a start wait time option for initialization by kinyoklion · Pull Request #71 · launchdarkly/openfeature-dotnet-server

kinyoklion · 2026-09-16T14:58:14Z

Aligns initialization with the OpenFeature provider spec (OFP) start wait requirements, so waiting for the client is bounded instead of unbounded.

New Provider(Configuration config, TimeSpan? startWait) constructor
A positive start wait time bounds construction, and InitializeAsync then reports the outcome without waiting again
TimeSpan.Zero waits nowhere; readiness is reported through provider events
null waits indefinitely for the data source to become valid or fail permanently, and stops when the cancellation token given to SetProviderAsync is canceled (fix: Honor the cancellation token when waiting for initialization #72)
Breaking: InitializeAsync no longer waits indefinitely after a configured StartWaitTime elapses

Implementation details

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

Sibling changes for the same OFP requirement: launchdarkly/openfeature-java-server#66, launchdarkly/openfeature-python-server#64, launchdarkly/openfeature-ruby-server#36.

Describe the solution you've provided

InitializeAsync still registers the flag and data source listeners and checks the current data source status. Only the indefinite mode leaves the initialization task pending; every other mode completes it with the outcome that is known at that point, so initialization does not wait a second time after the LaunchDarkly client constructor has already waited.

main was merged in after #72 (cancellation token) landed. InitializeAsync returns #72's WaitForInitializationAsync, so a canceled token abandons an indefinite wait. StatusProvider keeps this PR's initialization-completion signal for suppressing the event that completes initialization, and a canceled startup wait also lifts that suppression, which preserves #72's StartupWaitCanceled behavior.

The README feature matrix row for initialization and the asynchronous initialization section describe the three modes.

Describe alternatives you've considered

Interpreting a timeout only inside InitializeAsync would wait twice when StartWaitTime is also configured, and OFP treats the start wait time as a bound over construction plus initialization.

Additional context

Out of scope, per the audit request: the dependency injection package and the client-side paradigm.

Verified with dotnet test -f net8.0 after the merge (81 tests pass).

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

Note

Overview
Breaking: InitializeAsync no longer waits indefinitely after the LaunchDarkly client’s construction wait. It now completes with success or failure based on whether the client became ready within the configured start wait time (constructor StartWaitTime or the new Provider(Configuration, TimeSpan startWait) argument).

Adds Provider(Configuration, TimeSpan startWait), which applies that bound to construction and initialization as a single OFP-aligned window. TimeSpan.Zero skips all waiting and fails initialization unless the client is already ready (readiness can still arrive via provider events). Timeout.InfiniteTimeSpan uses zero construction wait but keeps InitializeAsync pending until the data source is valid, fails permanently, or the SetProviderAsync cancellation token fires.

StatusProvider now keys event suppression on initialization completion (and canceled startup wait) instead of a first-event flag, and Provider uses a completion lock so status updates and init outcomes stay consistent under concurrent data-source callbacks. README and tests cover the three modes and late-ready behavior after a failed init.

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

Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>

devin-ai-integration · 2026-09-16T14:58:18Z

🤖 Devin AI Engineer

I'll be helping with this pull request! Here's what you should know:

✅ I will automatically:

Address comments on this PR. Add '(aside)' to your comment to have me ignore it.
Look at CI failures and help fix them

Note: I can only respond to comments from users who have write access to this repository.

⚙️ Control Options:

Disable automatic comment, CI, and merge conflict monitoring

devin-ai-integration · 2026-09-16T15:02:29Z

@cursor review

kinyoklion · 2026-09-29T22:43:11Z

Devin check this against the latest version of the spec.

Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>

devin-ai-integration · 2026-09-29T22:59:25Z

Devin check this against the latest version of the spec.

Rechecked against the latest OFP spec (launchdarkly/sdk-specs at 7085813, "Clarify OpenFeature provider start wait behavior"). The start wait behavior in this PR still matches 4.3.4–4.3.7; one gap was found and fixed here: the provider stopped reporting status changes after a failed initialization, violating 4.3.3.

Provider.StatusProvider now takes an initialization-completion signal and suppresses events only up to that point, so 4.2.5 (no event for the transition which completes initialization) still holds while later transitions are emitted.
A failed initialization records ERROR without duplicating the error event the OpenFeature SDK already emits, and a later recovery to a valid data source emits provider ready.
Added ItReportsBecomingReadyAfterInitializationFailed.

dotnet test -f net8.0: 72 tests pass.

@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** - [x] I have added test coverage for new or changed functionality - [x] I have followed the repository's [pull request submission guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests) - [x] I have validated my changes against all supported platform versions **Related issues** None. <details> <summary>Implementation details</summary> 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](#71) also changes initialization waiting; whichever merges second needs a trivial rebase of this region. </details> 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](https://launchdarkly.atlassian.net/browse/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. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit afef99f. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup>  [SDK-3255]: https://launchdarkly.atlassian.net/browse/SDK-3255?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

@kinyoklion

Gives the OpenFeature providers the initialization waiting values the OpenFeature provider spec (OFP) requires, which the numeric-only `initTimeoutSeconds` could not express. - `initTimeoutSeconds: 'forever'` waits indefinitely for the LaunchDarkly client - `initTimeoutSeconds: 0` waits nowhere and fails initialization unless the client is already ready, so readiness is observed through provider events - A positive timeout behaves as before, and the default is still 10 seconds - Node provider README feature matrix row updated for the new values <details> <summary>Implementation details</summary> **Requirements** - [x] I have added test coverage for new or changed functionality - [x] I have followed the repository's [pull request submission guidelines](../blob/main/CONTRIBUTING.md#submitting-pull-requests) - [x] I have validated my changes against all supported platform versions **Related issues** OFP requirement 4.3.4 requires a value distinct from any duration to request waiting indefinitely, and 4.3.6 requires a zero wait to wait nowhere and fail initialization. Sibling changes for the same requirement: launchdarkly/openfeature-java-server#66, launchdarkly/openfeature-python-server#64, launchdarkly/openfeature-dotnet-server#71, launchdarkly/openfeature-ruby-server#36. **Describe the solution you've provided** `BaseProviderConfig.initTimeoutSeconds` and the Node provider's constructor parameter are now `number | 'forever'`, and zero is no longer coalesced into the default, since `??` only replaces `undefined`. `waitForInitialization` treats a falsy timeout as no timeout, so zero cannot be passed through: initialization races the pending initialization promise against an immediately rejected one, which succeeds only when the client is already ready. The Cloudflare provider is unaffected because it evaluates from a KV namespace and has no data source to wait for. **Describe alternatives you've considered** `number | null` was used initially for the indefinite case; `'forever'` reads better at the call site and matches the repository's preference for string unions. Adding `initialized()` to the client contract would let the zero case be checked directly, but that is a breaking change to a published interface for behavior the existing promise already expresses. **Additional context** Verified with `yarn workspace @launchdarkly/openfeature-js-server-common test` (82 tests), `yarn workspace @launchdarkly/openfeature-node-server test` (29 tests), and lint, format and build checks for both packages. </details> Link to Devin session: https://app.devin.ai/sessions/1fd3fcbfe79f482e8b58be29e8df2ffb Open in Devin Desktop: https://app.devin.ai/desktop/session/1fd3fcbfe79f482e8b58be29e8df2ffb?variant=devin Requested by: @kinyoklion  --- > [!NOTE] > **Overview** > Extends **`initTimeoutSeconds`** on the shared **`BaseOpenFeatureProvider`** and the Node **`LaunchDarklyProvider`** to **`number | 'forever'`**, aligning initialization with the OpenFeature provider spec. > > **`'forever'`** calls **`waitForInitialization()`** with no timeout. **`0`** no longer falls through to the 10-second default (only **`undefined`** does); initialization races the client’s init promise against an immediate failure so it succeeds only when the client is already ready, otherwise it throws a clear error. Positive timeouts behave as before (default **10** seconds). > > The Node provider README initialization row documents the new values, and unit tests cover indefinite wait, zero-timeout failure, and zero-timeout success when already ready. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 87e9a23. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup>  --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

…et-start-wait Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com> # Conflicts: # README.md # src/LaunchDarkly.OpenFeature.ServerProvider/Provider.StatusProvider.cs # src/LaunchDarkly.OpenFeature.ServerProvider/Provider.cs # test/LaunchDarkly.OpenFeature.ServerProvider.Tests/ProviderTests.cs

kinyoklion · 2026-10-16T21:19:41Z

+        /// <param name="config">A client configuration object</param>
+        /// <param name="startWait">How long to wait for the client to become ready, or null to wait indefinitely</param>
+        public Provider(Configuration config, TimeSpan? startWait)
+            : this(new LdClient(WrapConfig(config, startWait ?? TimeSpan.Zero)), startWait == null)


Why would we use null instead of TimeSpan.Infinite?

Good call — switched to it. The parameter is now TimeSpan startWait and Timeout.InfiniteTimeSpan is the indefinite sentinel, which also makes the signature non-nullable and matches Task.Delay/CancellationTokenSource conventions. Internally the provider still passes TimeSpan.Zero to StartWaitTime in that case, since the LaunchDarkly client's start wait would reject/ignore a negative timespan and the indefinite wait has to happen in InitializeAsync, not in the constructor. README and tests updated; 81 tests pass.

Correction on one detail above: the .NET SDK docs only define StartWaitTime for 0 and positive durations, and don't specify behavior for a negative timespan, so rather than rely on that the provider maps the infinite case to TimeSpan.Zero for client construction and does the indefinite wait in InitializeAsync.

…ting Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>

…it' into devin/1789570678-dotnet-start-wait Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com> # Conflicts: # README.md

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 5c072d5. Configure here.}

Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>

feat!: Add a start wait time option for initialization

aefff18

Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>

devin-ai-integration Bot assigned kinyoklion Sep 16, 2026

devin-ai-integration Bot added the devin-pr label Sep 16, 2026

kinyoklion mentioned this pull request Sep 16, 2026

feat: Support zero and indefinite initialization waiting launchdarkly/js-core#2024

Merged

3 tasks done

devin-ai-integration Bot mentioned this pull request Sep 16, 2026

feat!: Add a start wait time option for initialization launchdarkly/openfeature-java-server#66

Draft

3 tasks done

kinyoklion mentioned this pull request Sep 23, 2026

fix: Honor the cancellation token when waiting for initialization #72

Merged

3 tasks done

devin-ai-integration Bot and others added 2 commits September 29, 2026 22:46

fix: Report status changes after initialization has failed

874ba7b

Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>

fix: Do not duplicate the error event for a failed initialization

d6ceb05

Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>

kinyoklion mentioned this pull request Oct 7, 2026

docs: Note rejected SDK key retry in the initialization matrix row #77

Open

1 of 3 tasks

kinyoklion commented Oct 16, 2026

View reviewed changes

devin-ai-integration Bot and others added 2 commits October 16, 2026 21:21

fix: Use Timeout.InfiniteTimeSpan rather than null for indefinite wai…

d7b63b9

…ting Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>

Merge remote-tracking branch 'origin/devin/1789570678-dotnet-start-wa…

5c072d5

…it' into devin/1789570678-dotnet-start-wait Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com> # Conflicts: # README.md

kinyoklion marked this pull request as ready for review October 16, 2026 21:40

kinyoklion requested a review from a team as a code owner October 16, 2026 21:40

cursor Bot reviewed Oct 16, 2026

View reviewed changes

Comment thread src/LaunchDarkly.OpenFeature.ServerProvider/Provider.cs

fix: Record the initialization outcome atomically with the status

9e86074

Co-Authored-By: rlamb@launchdarkly.com <4955475+kinyoklion@users.noreply.github.com>

Navigation Menu

Repository navigation

feat!: Add a start wait time option for initialization - #71

feat!: Add a start wait time option for initialization#71
kinyoklion wants to merge 7 commits into
mainfrom
devin/1789570678-dotnet-start-wait

kinyoklion commented Sep 16, 2026 •

edited by cursor Bot

Loading

Uh oh!

devin-ai-integration Bot commented Sep 16, 2026

Uh oh!

devin-ai-integration Bot commented Sep 16, 2026

Uh oh!

kinyoklion commented Sep 29, 2026

Uh oh!

devin-ai-integration Bot commented Sep 29, 2026

Uh oh!

kinyoklion Oct 16, 2026

Uh oh!

devin-ai-integration Bot Oct 16, 2026

Uh oh!

devin-ai-integration Bot Oct 16, 2026

Uh oh!

cursor Bot left a comment

Uh oh!

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

kinyoklion commented Sep 16, 2026 • edited by cursor Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

devin-ai-integration Bot commented Sep 16, 2026

🤖 Devin AI Engineer

Uh oh!

devin-ai-integration Bot commented Sep 16, 2026

Uh oh!

kinyoklion commented Sep 29, 2026

Uh oh!

devin-ai-integration Bot commented Sep 29, 2026

Uh oh!

kinyoklion Oct 16, 2026

Choose a reason for hiding this comment

Uh oh!

devin-ai-integration Bot Oct 16, 2026

Choose a reason for hiding this comment

Uh oh!

devin-ai-integration Bot Oct 16, 2026

Choose a reason for hiding this comment

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

This branch has not been deployed

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

kinyoklion commented Sep 16, 2026 •

edited by cursor Bot

Loading