fix!: Use None rather than zero for indefinite initialization waiting

[kinyoklion]

Aligns start_wait with the OpenFeature provider spec (OFP), which requires a distinct non-duration value to request indefinite initialization waiting.

• start_wait=None now requests an indefinite wait: the constructor does not block and initialize waits until the data source becomes valid or fails permanently.
• start_wait=0 no longer waits indefinitely; it waits nowhere, so initialize reports a failed initialization unless the client is already ready, and readiness is observed through provider events.
• Positive values are unchanged: the constructor bounds the wait and initialize returns immediately with whatever the outcome is.
• Breaking for anyone relying on 0 meaning "wait forever".

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

OFP requires that a positive start wait bound total construction plus initialization, that zero wait nowhere, and that indefinite waiting avoid construction-time blocking and instead wait during initialize. Previously zero was overloaded to mean indefinite, leaving no way to express "no waiting at all".

None is now passed to LDClient as a zero construction wait, with the waiting performed in initialize against the data source status listener.

Testing: make test (88 tests) and make lint (mypy) pass. New tests cover the zero and indefinite cases, including that the constructor does not block when None is given.

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
Breaking: LaunchDarklyProvider’s start_wait now matches the OpenFeature provider contract instead of overloading 0 as “wait forever.”

start_wait=0 no longer blocks in initialize until the data source is ready. The constructor and initialize return quickly; initialization fails with ProviderNotReadyError unless the LD client is already ready, and apps should watch PROVIDER_READY (and related) events for late readiness.

start_wait=None is the new indefinite mode: construction passes 0 to LDClient (non-blocking), and initialize waits without a timeout until the data source is valid or permanently fails. Positive start_wait behavior is unchanged (constructor-bound wait, then immediate initialize outcome).

Provider lifecycle changes register data-source and flag listeners before the wait, track ProviderStatus with an initialization gate so the OpenFeature client owns the first ready/error signal, and still emit later transitions (e.g. ready after a failed init with start_wait=0). README and tests cover the new semantics, including DelayedReadyDataSource and recovery-after-failure event behavior.

^{Reviewed by Cursor Bugbot for commit 949ff46. 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

[kinyoklion]

Devin check this against the latest version of the spec.

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 2 potential issues.

^{❌ 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 6385f3e. Configure here.}

[devin-ai-integration]

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 semantics in this PR still match 4.3.4–4.3.7; the gap found was 4.3.3, the provider must keep reporting status changes after initialization has failed.

• The data source and flag listeners now stay registered after a failed initialization, and provider status is tracked so only genuine transitions are emitted.
• The initialization outcome is recorded and initialization completed under the same lock, so the OpenFeature SDK's own event for the initialization outcome is not duplicated (4.2.5) and a concurrent data source change cannot be dropped.
• Added test_ready_is_reported_after_initialization_failed.

poetry run pytest -q: 89 pass. poetry run mypy ld_openfeature tests: clean.