Skip to content

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

Draft
kinyoklion wants to merge 1 commit into
mainfrom
devin/1789570678-dotnet-start-wait
Draft

kinyoklion wants to merge 1 commit into
mainfrom
devin/1789570678-dotnet-start-wait

Conversation

@kinyoklion

Copy link
Copy Markdown
Member

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
  • 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

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.

The README feature matrix row for initialization and the asynchronous initialization section were updated to 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

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

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

Verified with dotnet test -f net8.0 (71 tests pass).

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

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

Copy link
Copy Markdown
Contributor

🤖 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

Copy link
Copy Markdown
Contributor

@cursor review

This branch has not been deployed

No deployments
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant