[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

SDK-3285

---

Note

Overview
Breaking change: start_wait now matches the OpenFeature provider contract instead of overloading 0 for “wait forever.”

start_wait=None means indefinite waiting only inside initialize (constructor passes 0 to LDClient so it does not block). start_wait=0 means no waiting anywhere—initialize fails immediately unless the client is already ready, and later readiness is surfaced via provider events. Positive values are unchanged.

Provider lifecycle updates track ProviderStatus, register data-source listeners before the readiness check, suppress duplicate events during initialization, and still emit PROVIDER_READY if the data source becomes valid after a failed init. README marks initialization fully supported; tests add DelayedReadyDataSource and cases for zero vs None and post-failure ready events.

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

---

AI review comment: the override below pins the next release to 0.9.0 — this repo's release-please config lacks bump-minor-pre-major, so this PR's fix!: commit escalated the open release PR to 1.0.0 instead of 0.9.0. A config fix is in flight; this override makes the correction effective on the next release-please run regardless.

BEGIN_COMMIT_OVERRIDE
fix!: Use None rather than zero for indefinite initialization waiting (#64)

start_wait=None now requests an indefinite wait performed in initialize();
start_wait=0 waits nowhere and reports failed initialization unless the
client is already ready. Breaking for anyone relying on 0 meaning "wait forever".

Release-As: 0.9.0
END_COMMIT_OVERRIDE

[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.