Repository navigation
fix: Make TestData value_for_all return its value when targeting is off - #490
Merged
Merged
Conversation
Generated-by: termag
keelerm84
marked this pull request as ready for review
November 5, 2026 19:14
jsonbailey
approved these changes
Nov 10, 2026
kinyoklion
added a commit
that referenced
this pull request
Nov 12, 2026
<!-- TERMAG_PR_BODY_BEGIN --> BEGIN_COMMIT_OVERRIDE feat: Add experimental support for flag overrides, read from local JSON or YAML files or supplied by a custom override source feat: Mark evaluations that a flag override affected with `override_affected` in the evaluation reason, and count them under separate summary counters END_COMMIT_OVERRIDE Every change in this PR was already reviewed and merged through its own PR against `feat/overrides`: #449, #450, #451, #452, #453, #454, #484, #493. This PR merges the branch into `main` and adds nothing of its own. Flag overrides let an operator force flags and segments to known definitions on a running client, whether or not the client can reach LaunchDarkly, and remove the override when the incident is over. They are an option of the FDv2 data system (`LaunchDarkly::DataSystem::ConfigBuilder#overrides`), with a file-based source in `LaunchDarkly::Integrations::FileData.override_source`, and are experimental. `main` has one commit that `feat/overrides` does not (#490), and the two merge without conflicts. CI on `feat/overrides` @ 156611b is green on every job, Windows included. <!-- TERMAG_PR_BODY_END --> <!-- termag: box=i-0575d1c54853058d7 project=ruby-server-sdk --> <sub>Opened from termag</sub> <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Overview** > Adds **experimental flag overrides** so operators can force known flag/segment definitions at evaluation time without replacing LaunchDarkly streaming or polling. > > **Configuration & data path.** FDv2 gains an optional override source via `DataSystemConfig` / `ConfigBuilder#overrides`. When set, the client builds an override layer, overlays it on the feature store for reads, and wires the layer’s dependency graph into the main store so prerequisite/segment changes still fan out to affected flags. Contract tests advertise `flag-overrides` and can wire file paths through `LaunchDarkly::Integrations::FileData.override_source`. > > **File-based source.** New `FileData` plumbing (parse/merge, poller, reloader with in-place rewrite handling, optional `listen`-based watcher) backs `FileData.override_source` with polling or watching, duplicate-key policy, and resilient reload/retry. The `listen` gem is added for contract tests’ watching mode. > > **Evaluation & analytics.** Flag/segment models carry an internal override marker. The evaluator propagates **override-affected** marking through prerequisites and segment matches; `EvaluationReason` exposes `overrideAffected` in JSON when true. Override-affected evaluations are excluded from individual and debug events but get **separate summary counters** keyed by the marker. > > **Client behavior.** Before initialization (or when the store is unavailable), evaluations and `all_flags_state` can serve override entries only, with one-time warnings. Docs/examples shift to `data_system_config: ... .build` instead of passing raw builders. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 156611b. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY -->
kinyoklion
pushed a commit
that referenced
this pull request
Nov 12, 2026
🤖 I have created a release *beep* *boop* --- ## [8.20.0](8.19.1...8.20.0) (2026-11-12) ### Features * Add experimental support for flag overrides, read from local JSON or YAML files or supplied by a custom override source ([9e2452c](9e2452c)) * Mark evaluations that a flag override affected with `override_affected` in the evaluation reason, and count them under separate summary counters ([9e2452c](9e2452c)) ### Bug Fixes * Ignore FDv2 objects with unrecognized kinds ([#468](#468)) ([168e199](168e199)) * Make TestData value_for_all return its value when targeting is off ([#490](#490)) ([dd484bb](dd484bb)) --- This PR was generated with [Release Please](https://github.com/googleapis/release-please). See [documentation](https://github.com/googleapis/release-please#release-please). <!-- CURSOR_SUMMARY --> --- > [!NOTE] > **Overview** > This PR **bumps the SDK from 8.19.1 to 8.20.0** via Release Please, updating `LaunchDarkly::VERSION`, the release manifest, provenance verification example, and **CHANGELOG** for the new release. > > The **8.20.0** notes document what ships in this version: **experimental flag overrides** (local JSON/YAML or a custom override source), evaluation reasons tagged with **`override_affected`** plus dedicated summary counters, ignoring **unrecognized FDv2 object kinds**, and a **TestData** fix so `value_for_all` returns its value when targeting is off. > > <sup>Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 4419601. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).</sup> <!-- /CURSOR_SUMMARY --> Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This is the FDv1 counterpart of #489, which fixes the same bug in
TestDataV2.TestData::FlagBuilder#value_for_allreplaced the variations with the single value and calledvariation_for_all(0), but left the off variation unchanged. A new test flag is a boolean flag with off variation 1, so the built flag hadvariations: [value]andoffVariation: 1. With targeting off, the index was out of range and the flag failed to evaluate. The method is documented to return the value regardless of whether targeting is on or off.value_for_allnow also sets the off variation to 0.variation_for_allis unchanged. A new spec builds the flag and checks thatoffVariationis 0 with targeting on and off.Opened from termag
Note
Overview
Fixes TestData
FlagBuilder#value_for_allso the configured value is returned when targeting is off, matching its documented behavior (FDv1 parity with the TestDataV2 fix in #489).Previously the method collapsed variations to a single entry and set fallthrough to index 0, but left the default boolean offVariation at 1. With targeting off, evaluation pointed at an invalid variation index and could fail. The implementation now also calls
off_variation(0)aftervariation_for_all(0).A new spec asserts
offVariationis 0 for flags built withvalue_for_all, including whenon(false).Reviewed by Cursor Bugbot for commit 77411c6. Bugbot is set up for automated code reviews on this repo. Configure here.