feat: Support waiting indefinitely for initialization by kinyoklion · Pull Request #36 · launchdarkly/openfeature-ruby-server

kinyoklion · 2026-09-02T14:50:38Z

Passing LaunchDarkly::OpenFeature::Provider::WAIT_INDEFINITELY as the wait time now asks the provider to wait for the LaunchDarkly client without a deadline.

WAIT_INDEFINITELY makes init wait until the data source becomes valid or fails permanently. The client constructor is given a wait time of zero, so it does not block, and the constant is never passed to the SDK as a wait time.
A wait time of zero keeps its duration meaning: nothing waits, and init reports a failed initialization unless the client is already ready.
A positive wait time is unchanged; the client constructor applies it and init does not wait a second time.
Since LaunchDarkly Ruby SDK 8.19.0 a rejected SDK key is retried rather than failing permanently, so the data source no longer reaches OFF for it and WAIT_INDEFINITELY can wait indefinitely. This is what the spec requires (OFP 4.3.7.3); the README row now says so.
Follows the initialization requirements of the OpenFeature provider behavior spec, which requires a value distinct from any duration to request indefinite waiting (OFP 4.3.4).

Found during the weekly OpenFeature provider audit. Earlier revisions of this PR overloaded a zero wait time, and then nil, to mean "wait indefinitely".

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

WAIT_INDEFINITELY is Float::INFINITY, so passing Float::INFINITY directly behaves the same. The LaunchDarkly Ruby SDK has no indefinite wait time for its constructor (wait_for_sec is a timeout, and nil is not accepted), so the provider passes zero to the constructor and does the waiting in init through the data source status provider.

When the wait is indefinite, init subscribes a DataSourceOutcomeListener to the data source status provider, then checks whether the client is already initialized or the data source is already OFF before blocking on a queue, so an outcome reached between construction and subscription is not missed. The listener is removed once an outcome arrives. VALID and OFF decide the outcome; INITIALIZING and INTERRUPTED leave the client still trying, so they do not end the wait.

Whether initialization succeeded is still decided by initialized?, and a failure still raises, which the OpenFeature SDK turns into the ERROR state. A failed initialization is not terminal: status changes keep flowing, so a later VALID state reports the provider as ready.

Describe alternatives you've considered

nil for an indefinite wait (the previous revision): a named constant is more explicit at the call site.

A non-numeric sentinel (e.g. a symbol): Float::INFINITY already reads as "no deadline" in Ruby and keeps the parameter numeric.

Applying a default timeout: an indefinite wait is the caller asking for no deadline, and the OpenFeature SDK decides how long to wait for a provider.

Polling initialized?: the data source status provider already reports transitions, so polling would only add latency and wake-ups.

Additional context

Testing: bundle exec rspec (84 examples) and bundle exec rubocop on Ruby 3.4. Tests cover an indefinite wait succeeding once the data source becomes valid, the client constructor receiving zero for an indefinite wait, an indefinite wait for an outcome arriving after init is called, a zero wait time not waiting at all, a positive wait time not waiting a second time, and the outcome listener's per-state behavior.

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

Note

Overview
Adds Provider::WAIT_INDEFINITELY (Float::INFINITY) so callers can block in init until the LaunchDarkly data source reaches a first-connection outcome (VALID or permanent OFF) instead of relying only on the constructor timeout. For that mode the LDClient is constructed with wait time 0; waiting happens via a new DataSourceOutcomeListener and wait_for_data_source_outcome.

Provider lifecycle and events are tightened for OpenFeature: init records the initial ready/error status without duplicating SDK init events; runtime data-source transitions go through new emit_status_event, which suppresses redundant events and defers emission until initialization completes (while still allowing later recovery after a failed init). shutdown now removes data-source and flag listeners before closing the client.

The README initialization row documents indefinite wait and LaunchDarkly Ruby SDK 8.19.0+ retry behavior for rejected keys. Specs cover indefinite wait paths, zero/positive wait unchanged behavior, outcome listener states, and event deduplication.

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

devin-ai-integration · 2026-09-02T14:50:41Z

🤖 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-02T14:50:47Z

@cursor review

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

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

@cursor review

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

@kinyoklion

The provider's data source status and flag change listeners stayed registered on the LaunchDarkly client after `shutdown`, so a provider which the OpenFeature SDK had already replaced could still emit events. They are now removed before the client is closed. Event deduplication and the events emitted after a failed initialization, which this PR previously carried, now live in [#36](#36) instead; this branch has been merged with that one and keeps only the `shutdown` change. Review [#36](#36) first. Found during the weekly OpenFeature provider audit. <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** None. **Describe the solution you've provided** The listeners the constructor registers are kept on the provider so that `shutdown` can pass them to `remove_listener` on the data source status provider and the flag tracker before closing the client. **Describe alternatives you've considered** Relying on `close` alone: the LaunchDarkly client stops notifying listeners once it is closed, but the provider is the owner of those subscriptions and a closed client is not a guarantee the OpenFeature SDK makes about a replaced provider. **Additional context** Testing: `bundle exec rspec` (83 examples) and `bundle exec rubocop` on Ruby 3.4.5. The `shutdown` spec now asserts both listeners are removed as well as the client being closed. </details> Link to Devin session: https://app.devin.ai/sessions/fe1eb757fe694ef79f3d09f6307d4b47 Open in Devin Desktop: https://app.devin.ai/desktop/session/fe1eb757fe694ef79f3d09f6307d4b47?variant=devin Requested by: @kinyoklion --------- Signed-off-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Co-authored-by: Devin AI <devin-ai-integration[bot]@users.noreply.github.com> 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>

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

kinyoklion · 2026-10-30T23:23:09Z

Devin can we use some constant to represent waiting forever instead of nil? If we do, then make sure we won't pass a giant number to the SDK and instead use its canonical way of waiting forever.

devin-ai-integration · 2026-10-30T23:23:13Z

❌ Cannot revive Devin session - the session is too old. Please start a new session instead.

View session

… initialization waiting Co-Authored-By: Ryan Lamb <4955475+kinyoklion@users.noreply.github.com>

devin-ai-integration · 2026-10-30T23:28:18Z

Devin can we use some constant to represent waiting forever instead of nil? If we do, then make sure we won't pass a giant number to the SDK and instead use its canonical way of waiting forever.

Done in 2bfcb5c. nil is replaced by LaunchDarkly::OpenFeature::Provider::WAIT_INDEFINITELY (it is Float::INFINITY).

The constant never reaches the SDK. The Ruby SDK has no way to wait forever in its constructor: wait_for_sec is only a timeout, and nil fails on wait_for_sec > 0. So for WAIT_INDEFINITELY the provider passes 0 to LDClient.new and does the waiting in init by listening to the data source status provider. A new spec asserts that the constructor receives 0.

Written by Devin

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 2bfcb5c. Configure here.}

…wait subscribes Co-Authored-By: Ryan Lamb <4955475+kinyoklion@users.noreply.github.com>

@kinyoklion

**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** Fixes #58. **Describe the solution you've provided** Adds `Provider(String sdkKey, LDConfig config, Duration startWait)` so an application can bound, or deliberately opt out of, waiting for initialization, matching the OpenFeature provider spec (OFP) requirements for start wait behavior: - a positive `Duration` is applied by the LaunchDarkly client constructor, and `initialize` then reports whether the client became ready without waiting a second time - `Duration.ZERO` waits nowhere; `initialize` fails unless the client is already ready, and the application learns when it becomes usable from provider events - `Provider.INFINITE_START_WAIT` requests indefinite waiting: nothing is waited for during construction and `initialize` blocks until the data source becomes valid or fails permanently The existing constructors keep honouring `LDConfig.Builder.startWait(...)` and no longer wait again in `initialize`, so a configured start wait is the only bound on initialization instead of being followed by an unbounded wait. The README feature matrix row and initialization section describe the new behavior. <details> <summary>Implementation details</summary> `initialize` still registers data source and flag change listeners and evaluates the current data source status. Only the indefinite mode leaves the completion future pending; every other mode completes it with the outcome that is already known, so `initialize` returns promptly. The OpenFeature SDK emits its own event for the transition that completes initialization, so the provider records that one state without emitting a duplicate, and emits every state change after it — including a permanent failure that arrives immediately after the data source became valid, and a recovery after a failed initialization. </details> **Describe alternatives you've considered** Keeping the existing indefinite wait and adding a timeout parameter interpreted only inside `initialize` would double-wait when `LDConfig.startWait` is also set, and would not match OFP, which treats the start wait as a bound over construction plus initialization. Java has no built-in infinite `Duration`, so indefinite waiting was initially expressed as `null`. It is now the explicit `Provider.INFINITE_START_WAIT` constant, matching `Timeout.InfiniteTimeSpan` in the .NET provider. **Additional context** Sibling changes for the same OFP requirement: launchdarkly/openfeature-python-server#64, launchdarkly/openfeature-ruby-server#36, launchdarkly/openfeature-dotnet-server#71, and launchdarkly/js-core#2024. Verified with `./gradlew test` (all tests pass, including new coverage for positive, zero, and indefinite start wait). 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](https://launchdarkly.atlassian.net/browse/SDK-3285)  --- > [!NOTE] > **Overview** > Fixes OpenFeature initialization behavior (**#58**) by adding **`Provider(String, LDConfig, Duration startWait)`** and **`Provider.INFINITE_START_WAIT`**, so startup waiting is bounded in one place instead of blocking again indefinitely inside **`initialize()`** after **`LDConfig.startWait`**. > > **Positive durations** apply during client construction; **`Duration.ZERO`** fails fast unless already ready; **indefinite** mode skips construction blocking and waits in **`initialize()`** until the data source is valid, fails, or the provider shuts down. Oversized durations are treated as indefinite to avoid SDK millis overflow. > > **`initialize()`** is reworked around a completion future and tighter state/event handling: failed init surfaces data-source errors, duplicate **STALE**/**READY** events are deduped, teardown **OFF** does not emit **PROVIDER_ERROR**, and **`shutdown()`** calls **`super.shutdown()`** to stop leaking the event executor. README documents cancellation of indefinite **`setProviderAndWait`** (direct **`provider.shutdown()`** vs API lock contention). > > Lifecycle tests cover bounded/zero/infinite waits, recovery, and classification boundaries. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 1c96e64. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup>  --- ## tanderson-ld additional changes Review-driven hardening of the start wait time behavior, on top of the commits above. Summary of the delta: **Indefinite wait is now cancellable.** `shutdown()` completes the initialization future, and the interrupt flag is restored if the waiting thread is interrupted. The README and constructor javadoc document how to cancel an indefinite `setProviderAndWait`: call `provider.shutdown()` directly from another thread, or register with the non-blocking `setProvider`. `OpenFeatureAPI.shutdown()` **cannot** end such a wait — it blocks on the same API lock `setProviderAndWait` holds for the duration of initialization. This lock-contention deadlock is inherent to the OpenFeature Java SDK (it holds the API write lock across a synchronous `initialize()` and contends on it in `shutdown()`), so it is documented rather than worked around; an upstream issue will be filed against the OpenFeature Java SDK. **Start wait time classification / validation.** - Any start wait time too large to represent in milliseconds — including `Provider.INFINITE_START_WAIT` and any other "forever" duration — is classified as indefinite, so it saturates to the indefinite path instead of overflowing when the SDK converts it to milliseconds. (Separately, a too-large duration configured through `LDConfig.Builder.startWait` instead of the constructor still overflows inside the SDK client constructor and leaks the client; that is pre-existing SDK behavior and has been filed as a separate java-core ticket. The sentinel is documented as constructor-argument-only.) - A `null` start wait time falls through to the SDK's default start wait rather than throwing. **Status / event fidelity.** - A failed initialization carries the data source's last error into the thrown exception, so the OpenFeature error event reports the cause rather than a generic message. - The client's `isInitialized()` latch no longer reports `READY` when the data source is currently `OFF`. - Repeated interruptions emit one `PROVIDER_STALE` per state change (state-based dedupe, retained and documented), and stale events now carry the HTTP error detail. **Lifecycle cleanup.** `shutdown()` removes its flag-change and data-source status listeners and calls `super.shutdown()` to terminate the event emitter executor. **Tests.** Added lifecycle coverage for bounded / zero / indefinite waits, failed-init-then-recovery, interruption → stale → ready, single-stale-per-outage dedupe, cancellation of an indefinite `setProviderAndWait` via a direct `provider.shutdown()`, the `OFF`-while-initialized exclusion, listener removal on shutdown, and a direct unit test of the start-wait classification boundary. Full suite and checkstyle pass. [SDK-3285]: https://launchdarkly.atlassian.net/browse/SDK-3285?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Co-authored-by: Todd Anderson <tanderson@launchdarkly.com>

fix: Wait for the data source when no start wait time is configured

e51f731

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

devin-ai-integration Bot added the devin-pr PRs created by Devin label Sep 2, 2026

kinyoklion mentioned this pull request Sep 2, 2026

fix: Unsubscribe the provider's listeners on shutdown #37

Merged

3 tasks done

fix: Wait for the data source when no start wait time is configured

7b1616a

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

devin-ai-integration Bot changed the title ~~fix: Wait for the data source when no start wait time is configured~~ feat: Support waiting indefinitely for initialization Sep 16, 2026

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

fix: Do not emit duplicate or unchanged provider status events

9a48135

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

docs: Note that a rejected SDK key is retried since Ruby SDK 8.19.0

895ccea

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

devin-ai-integration Bot mentioned this pull request Oct 28, 2026

Emit provider lifecycle events from the provider now that the OpenFeature Ruby SDK supports opting in #39

Open

kinyoklion mentioned this pull request Oct 28, 2026

docs: Update the feature matrix for OpenFeature Ruby SDK 0.7 and LaunchDarkly Ruby SDK 8.19 #40

Draft

feat: Use a WAIT_INDEFINITELY constant rather than nil for indefinite…

2bfcb5c

… initialization waiting Co-Authored-By: Ryan Lamb <4955475+kinyoklion@users.noreply.github.com>

kinyoklion marked this pull request as ready for review October 30, 2026 23:38

kinyoklion requested a review from a team as a code owner October 30, 2026 23:38

cursor Bot reviewed Oct 30, 2026

View reviewed changes

Comment thread lib/ldclient-openfeature/provider.rb Resolved

fix: Do not miss a data source outcome reached before the indefinite …

4abc4f4

…wait subscribes Co-Authored-By: Ryan Lamb <4955475+kinyoklion@users.noreply.github.com>

Navigation Menu

Repository navigation

feat: Support waiting indefinitely for initialization - #36

feat: Support waiting indefinitely for initialization#36
kinyoklion wants to merge 7 commits into
mainfrom
devin/1788360613-ruby-zero-start-wait

kinyoklion commented Sep 2, 2026 •

edited by cursor Bot

Loading

Uh oh!

devin-ai-integration Bot commented Sep 2, 2026

Uh oh!

devin-ai-integration Bot commented Sep 2, 2026

Uh oh!

devin-ai-integration Bot commented Sep 16, 2026

Uh oh!

kinyoklion commented Oct 30, 2026

Uh oh!

devin-ai-integration Bot commented Oct 30, 2026

Uh oh!

devin-ai-integration Bot commented Oct 30, 2026

Uh oh!

cursor Bot left a comment

Uh oh!

Uh oh!

This branch has not been deployed

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

Conversation

kinyoklion commented Sep 2, 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 2, 2026

🤖 Devin AI Engineer

Uh oh!

devin-ai-integration Bot commented Sep 2, 2026

Uh oh!

devin-ai-integration Bot commented Sep 16, 2026

Uh oh!

kinyoklion commented Oct 30, 2026

Uh oh!

devin-ai-integration Bot commented Oct 30, 2026

Uh oh!

devin-ai-integration Bot commented Oct 30, 2026

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

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

1 participant

kinyoklion commented Sep 2, 2026 •

edited by cursor Bot

Loading