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

SDK-3285

Note

Overview
Adds LaunchDarkly::OpenFeature::Provider::WAIT_INDEFINITELY (Float::INFINITY) so callers can block in init until the LaunchDarkly data source becomes valid or permanently off, instead of relying only on the client constructor timeout. For that mode the constructor still gets wait time 0; init waits via a new DataSourceOutcomeListener and wait_for_data_source_outcome, without re-waiting when a finite timeout was already applied in the constructor.

Provider lifecycle events are tightened: status transitions go through emit_status_event, which suppresses duplicate statuses, skips emission while initialization is in progress (OpenFeature still owns the init outcome event), and allows later recovery events after a failed init. shutdown now removes data-source and flag listeners before closing the client.

The README feature matrix is updated for indefinite init and the revised eventing behavior, with expanded specs covering indefinite wait paths and status emission rules.

^{Reviewed by Cursor Bugbot for commit 8218e72. 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. > > 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).  --------- 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. > > 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).  --- ## 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>

#43) **Requirements** - [ ] 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** `build-linux (jruby-10.0)` fails on #36 (and any PR that runs CI) since `ubuntu-latest` moved to `ubuntu-26.04`. **Describe the solution you've provided** Bumps the pinned `ruby/setup-ruby` from v1.299.0 to v1.336.0 (`de492cf`) in the CI action, the Windows job, and the docs publish workflow. v1.299.0 does not list `ubuntu-26.04-x64` as a GitHub-hosted platform, so it treats the runner as self-hosted and refuses to install JRuby: ``` The current runner (ubuntu-26.04-x64) was detected as self-hosted because the platform does not match a GitHub-hosted runner image ``` v1.336.0 includes `ubuntu-26.04-x64` and `ubuntu-26.04-arm64` in `GitHubHostedPlatforms`. **Describe alternatives you've considered** Pinning `runs-on: ubuntu-24.04`: works, but defers the problem and diverges from the other jobs. **Additional context** CI-only change; no release needed. Found during the weekly OpenFeature provider audit. Link to Devin session: https://app.devin.ai/sessions/a5c7e7288f924650ba0ccbd5417d33d2 Open in Devin Desktop: https://app.devin.ai/desktop/session/a5c7e7288f924650ba0ccbd5417d33d2?variant=devin [SDK-3499](https://launchdarkly.atlassian.net/browse/SDK-3499)  --- > [!NOTE] > **Overview** > Pins **`ruby/setup-ruby`** from **v1.299.0** to **v1.336.0** in the shared CI composite action (`.github/actions/ci/action.yml`), the Windows CI job in `ci.yml`, and the manual docs publish workflow. > > This restores Linux CI (including **JRuby**) after **`ubuntu-latest`** switched to **ubuntu-26.04**: the older action did not treat that image as GitHub-hosted and failed Ruby/JRuby setup. No application or runtime code changes. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit a340e63. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).  [SDK-3499]: https://launchdarkly.atlassian.net/browse/SDK-3499?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

…-zero-start-wait

@kinyoklion

…chDarkly Ruby SDK 8.19 (#40) Updates the README feature matrix after the OpenFeature Ruby SDK 0.6.6–0.8.1 releases (2026-10-22/23) and LaunchDarkly Ruby SDK 8.19.0. - **Eventing** goes from ✅ to ⚠️, listing two provider gaps: - A data source update that leaves the provider status unchanged is emitted again (fix in #36). - The provider relies on SDK-emitted `PROVIDER_READY`/`PROVIDER_ERROR`, which OpenFeature Ruby SDK 0.7.0 deprecates (tracked in #39). - **Initialization** notes that since LaunchDarkly Ruby SDK 8.19.0 a rejected SDK key is retried, so the constructor waits the full wait time before initialization fails. - **Domains** notes that the provider is not domain-scoped (`domain_scoped?`, OpenFeature Ruby SDK 0.6.7). <details> <summary>Details</summary> - Duplicate events: LaunchDarkly Ruby SDK's `DataSourceUpdateSinkImpl#update_status` broadcasts again when the state is unchanged but there is a new error. `DataSourceStatusListener` emits every broadcast, so one `INTERRUPTED` period can produce several `PROVIDER_STALE` events (OFP 4.2.2). #36 already adds the status de-duplication. - Deprecation: in OpenFeature Ruby SDK 0.7.0 (open-feature/ruby-sdk#353), a provider with `init` but without `emits_lifecycle_events?` takes the legacy path, and the SDK logs a deprecation warning once per provider class. The gemspec's `~> 0.6.1` keeps 0.7 out of range today, and #38 widens it. #39 describes the follow-up and what blocks it: #38, #36, the Bundler cooldown, and a needed OFP 4.2.5 update. - Rejected key: in 8.19.0 the stream and polling data sources report `INTERRUPTED` and retry after any failure, and they go to `OFF` only from `stop`. `@ready` is set only on success, so a rejected key keeps the constructor waiting for the full `wait_for_seconds`. - Other changes in 0.6.6–0.8.1 need no provider change: - Hook inputs are immutable and flag metadata is frozen. The provider builds a new metadata hash on each evaluation. - Clients resolve their domain's provider on every call. - Isolated API instances are supported. The provider includes `EventEmitter`, so the SDK rejects registering one instance with two APIs. - `PROVIDER_RECONCILING`/`PROVIDER_CONTEXT_CHANGED` are static-context events and don't apply to a server provider. - Docs only, so no changelog entry or release. </details> Link to Devin session: https://app.devin.ai/sessions/b215bd8a675f4cc39541f1741d4013b7 Open in Devin Desktop: https://app.devin.ai/desktop/session/b215bd8a675f4cc39541f1741d4013b7?variant=devin Requested by: @kinyoklion [SDK-3423](https://launchdarkly.atlassian.net/browse/SDK-3423) [SDK-3423]: https://launchdarkly.atlassian.net/browse/SDK-3423?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ  --- > [!NOTE] > **Overview** > Updates the README **feature matrix** to reflect OpenFeature Ruby SDK 0.7.x and LaunchDarkly Ruby SDK **8.19.0** behavior—documentation only, no code changes. > > **Eventing** is downgraded from fully supported to **partially supported (⚠️)** with notes on two known gaps: duplicate provider events when the data source status stays the same but errors update ([#36](#36)), and reliance on SDK-emitted init lifecycle events that 0.7.0 deprecates ([#39](#39)). > > **Initialization** now explains that rejected SDK keys are retried in 8.19.0, so `init` may block for the full configured wait before reporting failure. **Domains** clarifies the provider is not domain-scoped, so one provider instance can back multiple OpenFeature domains with a shared LaunchDarkly client. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 7cac07d. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).  Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com>

…-zero-start-wait Co-Authored-By: Ryan Lamb <4955475+kinyoklion@users.noreply.github.com> # Conflicts: # README.md

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

Merged

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>

kinyoklion mentioned this pull request Nov 5, 2026

ci: Update ruby/setup-ruby to v1.336.0 to support ubuntu-26.04 runners #43

Merged

2 of 3 tasks

Merge remote-tracking branch 'origin/main' into devin/1788360613-ruby…

365864b

…-zero-start-wait

Merge remote-tracking branch 'origin/main' into devin/1788360613-ruby…

8218e72

…-zero-start-wait Co-Authored-By: Ryan Lamb <4955475+kinyoklion@users.noreply.github.com> # Conflicts: # README.md

Navigation Menu

Repository navigation

feat: Support waiting indefinitely for initialization - #36

feat: Support waiting indefinitely for initialization#36
kinyoklion wants to merge 9 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