chore: Do not use the configured start wait time to bound initialization

[kinyoklion]

Intentionally chore. I am removing the changelog as it has not been released.

Reverts #60 and #66, restoring the pre-2.2.0 initialization behavior.

• StartWaitTime is a Configuration property, so it belongs to the client constructor's blocking behavior; the provider no longer reuses it to bound InitializeAsync.
• InitializeAsync again waits for the client to become ready or to fail permanently, with no timeout of its own; callers bound the wait by choosing whether to await SetProviderAsync.
• README feature matrix and asynchronous-initialization section updated to describe the restored behavior.

Requirements

• I have added test coverage for new or changed functionality (tests added by the reverted PRs are removed)
• I have followed the repository's pull request submission guidelines
• I have validated my changes against all supported platform versions

Implementation details

Related issues

Reverts #60 ("Stop waiting for initialization after the configured start wait time", released in 2.2.0) and #66 ("Resolve initialization immediately when a start wait time was used", pending release in 2.3.1).

Describe the solution you've provided

git revert of both commits, so Provider.cs is byte-identical to its state at ed29935 (immediately before #60): the internal startWait constructor parameter, the StartWait(config) helper, FailInitializationIfNotReady, and the _initLock around the Valid status transition are all gone. The README matrix row for Initialization is rewritten rather than restored verbatim, because the text #64 added described the #60 behavior.

The rationale: StartWaitTime lives on Configuration, not on the provider constructor, and the LaunchDarkly client constructor has already consumed it before OpenFeature ever calls InitializeAsync. Deriving an OpenFeature initialization deadline from it made the same value mean two different things, and made a non-awaited SetProviderAsync put the provider into ERROR for a merely slow start.

Describe alternatives you've considered

Keeping #66 and only adjusting the messaging, or exposing an explicit provider-level initialization timeout parameter. Neither was pursued: the requested outcome is the original behavior, where the caller controls how long to wait by awaiting SetProviderAsync or not.

Additional context

Behavior after this revert, per registration style:

• SetProviderAsync(provider) not awaited: initialization runs in the background and waits for readiness; a PROVIDER_READY event is emitted whenever the data source becomes valid.
• SetProviderAsync(provider) awaited: waits until the data source becomes valid or permanently fails. With a positive StartWaitTime the client constructor has already blocked for that long, so the remaining wait is unbounded — use StartWaitTime to bound constructor blocking and the OpenFeature PROVIDER_ERROR/PROVIDER_READY events to observe later state.

dotnet test passes on net8.0 (68 tests); net471 and net6.0 runtimes are unavailable in this environment and are covered by CI.

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

---

Note

Overview
Reverts the 2.2.x behavior where StartWaitTime also capped OpenFeature InitializeAsync. InitializeAsync again waits until the LaunchDarkly data source is ready or permanently fails, with no provider-level timeout; StartWaitTime only affects blocking in the LdClient constructor.

The provider drops the internal start-wait plumbing (FailInitializationIfNotReady, StartWait(config), and the extra lock on the Valid status path). README Initialization and Asynchronous initialization text is updated to match. Tests that asserted init timeout / late-ready after timeout are removed.

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

[devin-ai-integration]

🤖 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]

@cursor review