feat: Add flag overrides to the contract test service by kinyoklion · Pull Request #454 · launchdarkly/ruby-server-sdk

kinyoklion · 2026-09-25T22:51:32Z

Summary

This PR is stacked on #453 because the test service configures the file-based override source that PR adds.

The contract test service now advertises the flag-overrides capability and accepts the overrides block of the SDK configuration described in the test harness service specification. filePaths, duplicateKeysHandling, changeDetection, and pollIntervalMs map to the options of LaunchDarkly::Integrations::FileData.override_source, which is set on the FDv2 data system builder. An overrides block without a dataSystem block is an error, as in the Go reference service.

The listen gem joins the contract test bundle so that the harness's watching change detection tests can run. The service port can be set with the PORT environment variable and still defaults to 9000, so the existing Makefile and CI steps are unchanged.

Verification against the prebuilt harness (sdk-test-harness branch rlamb/sdk-2657/flag-overrides-tests at 9ad082c, flag-overrides capability): -run 'flag overrides' ran 38 tests with 0 failures, and the full suite with no filter ran 4733 tests with 0 failures (13 skipped by pre-existing capability and long-running gates). The first run of the watching mode tests failed because the watcher relied on listen, which could not scan the system temporary directory where the harness writes its files; the watcher change in #449 corrects that, and both runs above were made with it in place.

The existing FDv1 and FDv2 file data sources keep their current behavior. This series does not change them; the override feature is additive.

SDK-3249

Note

Overview
Enables the Ruby contract test client to wire the FDv2 overrides block to LaunchDarkly::Integrations::FileData.override_source, mapping harness fields to paths, duplicate-keys handling, change-detection mode, and optional polling interval, and rejects overrides when no dataSystem is configured to match harness expectations.

Advertises the flag-overrides capability from the test service, allows the bind port to be overridden via PORT (default 9000), and adds the listen gem to support watching change detection for file-based overrides.

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

kinyoklion · 2026-10-03T01:23:54Z

bugbot review

cursor

Stale Bugbot comment from a previous run.

kinyoklion · 2026-10-28T22:54:17Z

bugbot review

cursor

Stale Bugbot comment from a previous run.

kinyoklion · 2026-10-28T23:29:24Z

bugbot review

cursor

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

^{Reviewed by Cursor Bugbot for commit 34cc17c. Configure here.}

…ide-affected evaluations Carries the override-affected marking from evaluation into analytics events, as the OVERRIDE specification requires. - `EvalEvent` and `record_eval_event` carry an `override_affected` flag. The client sets it from the evaluation result for the evaluated flag, from each prerequisite record's own marking for prerequisite evaluations, and from the flag's own marker when an evaluation raises. An unknown flag is never marked. - The event dispatcher produces no individual feature event and no debug event for a marked evaluation, whatever the flag's configuration requests. Marked evaluations appear in summary events only. - The summarizer keys counters by version, variation, and the marker, so override-affected and other evaluations of the same flag, variation, and version accumulate into separate counters. The summary event writes `overrideAffected: true` on the marked counters only, like the existing `unknown` marker. - `all_flags_state` presents an override-affected flag with `trackEvents` false, `trackReason` false, and no `debugEventsUntilDate`. The flag, its value, its version, and its reason stay in the state. The specification vectors now also check the summary marker the client hands to the event processor for each evaluation. Flag overrides are currently experimental and subject to change.

…raises When the evaluator raises in all_flags_state there is no evaluation result, so the state kept trackEvents, trackReason, and debugEventsUntilDate for an overridden flag. The flag's own override marker now decides, as it does for the reason and for the event of a single evaluation.

…jects A custom store can return a flag as a plain hash, as the FeatureStore interface documents. When its evaluation raised, the error event and the all_flags_state tracking fallback called override? on the hash and raised NoMethodError. Both now use the helper that reads the marker only from an object that has it, so such a failure is unmarked and keeps the flag's tracking, as before overrides.

Adds `LaunchDarkly::Integrations::FileData.override_source`, the file-based override source that the OVERRIDE specification defines, for use with `LaunchDarkly::DataSystem::ConfigBuilder#overrides`. The source reads one or more JSON or YAML files in the file data source document format (`flags`, `flagValues`, `segments`) and supplies complete snapshots to the SDK's override store. Options: `paths` (required, in precedence order), `duplicate_keys_handling` (`:fail`, the default, or `:ignore`, which keeps the first file's entry), `change_detection` (`:polling`, the default, or `:watching` through the optional listen gem), and `poll_interval` (default 1 second, raised to the 1 second minimum with a warning). Invalid options, including an unknown option key, raise `ArgumentError` when the client is created. Behavior comes from the shared file data code: a configured file that does not exist contributes no overrides, so a file can be created later and deleting a file removes its overrides. A file that exists but cannot be read or parsed fails that reload and keeps the last good overrides, with a logged failure and a retry. A rewrite with identical content is not reapplied. The initial load completes before the client constructor returns. A `flagValues` entry expands into a flag that is off and serves the value, so the evaluation reports the OFF reason kind. Every applied change is logged at Info with the overrides in effect and what each file supplied. The reloader's log lines for this source carry a FileOverrideSource prefix. Flag overrides are currently experimental and subject to change.

…ntries as duplicate keys A path listed more than once would make every entry of that file a duplicate of itself: under the default fail handling the load failed, and under ignore the first listing won by accident. The builder now drops the repeats, keeps the first occurrence in its place in the order, and logs a warning once at build time. This is the behavior the Node SDK has.

…t on Windows

… SDKs A flagValues entry becomes a flag without client-side availability, so all_flags_state with client_side_only leaves it out even when the flag it overrides is client-side. A full definition with clientSide is the way to override such a flag. A spec pins both.

The override source chooses each file's format by its name: a name that ends in .yaml or .yml, in any case, is YAML, and any other file is JSON. Files must be UTF-8. An override file can be rewritten in place: while the source finds a file empty during a rewrite, it keeps the overrides in effect until the new content is written. An empty JSON file is not a valid document; to remove a file's overrides, delete it or write `{}`. The override source tests rewrite their files in place, and end-to-end tests check that the source never supplies a snapshot without the override, and that a client never serves the LaunchDarkly value, while a JSON or YAML file is rewritten in place with polling and watching change detection; also for a YAML file that starts with a comment, for rewrites about once a second with the default timing, and for files that are not UTF-8.

Watching follows edits to the configured files and to the targets of configured links, including a ConfigMap update, but not a link further along the path or a configured directory that is pointed elsewhere or replaced. The change detection documentation now says so and points such deployments to polling.

…, in every example Config reads the data system configuration from the data_system_config option and ignores unknown keys, so the examples that passed it as data_system gave a client without that configuration, and without an override source in the override_source example. The DataSystem builders also need build. The override_source, data_source_v2, and DataSystem module examples now pass data_system_config with a built configuration.

The test service advertises the flag-overrides capability and accepts the overrides block of the SDK configuration: filePaths, duplicateKeysHandling, changeDetection, and pollIntervalMs map to the options of LaunchDarkly::Integrations::FileData.override_source on the FDv2 data system builder. Overrides without a data system configuration are an error. The listen gem joins the contract test bundle so that the watching change detection mode can run. The service port can be set with the PORT environment variable and still defaults to 9000.

## Summary This PR is stacked on #452 because it supplies the override store that the earlier PRs add, and its client-level spec relies on the marked reasons and events they produce. This change adds `LaunchDarkly::Integrations::FileData.override_source`, the file-based override source that the OVERRIDE specification defines. It is configured with `LaunchDarkly::DataSystem::ConfigBuilder#overrides`: ```ruby overrides = LaunchDarkly::Integrations::FileData.override_source(paths: ["/etc/launchdarkly/overrides.json"]) config = LaunchDarkly::Config.new(data_system_config: LaunchDarkly::DataSystem.default.overrides(overrides).build) ``` The source reads one or more JSON or YAML files in the file data source document format (`flags`, `flagValues`, `segments`) and supplies complete snapshots to the SDK's override store. Its options are `paths` (required, non-empty strings in precedence order; a path listed more than once is logged and the repeats are ignored; on Windows, where file names ignore case, paths that differ only in case count as the same path), `duplicate_keys_handling` (`:fail`, the default, or `:ignore`, which keeps the first file's entry), `change_detection` (`:polling`, the default, or `:watching` through the optional `listen` gem), and `poll_interval` (default 1 second, raised to the 1 second minimum with a warning). Invalid options raise `ArgumentError` when the client is created, the same way other invalid component configuration is reported. Unlike the Go reference, an unrecognized `duplicate_keys_handling` value and an unknown option key are rejected rather than defaulted, because the specification treats invalid configuration as a construction error and an emergency mechanism should fail loudly. Behavior comes from the shared file data code added in #449: - The format comes from each file's name, as sdk-specs #272 recommends: a name that ends in `.yaml` or `.yml`, in any case, is YAML, and any other file, including one with no extension, is JSON. The existing file data sources read every file with the YAML parser, which also reads most JSON; the override source does not, so a YAML document in a `.json` file, or JSON with a `#` comment or a trailing comma, does not load. Files must be UTF-8; a UTF-16 file, as Windows PowerShell 5.1 writes with `>`, fails to load with a clear message and keeps the overrides in effect. - An empty JSON file is not a valid document: it fails to load and the overrides in effect stay. To remove a file's overrides, delete the file or write `{}`. - Override files can be rewritten in place. When the source finds a file whose overrides are in effect empty (or, for YAML, with only a comment or `---`), it holds the file back and keeps the overrides in effect until the new content is written: until the file has stayed so, unwritten, for one retry delay (1 second), and for at most five retry delays while it keeps being rewritten. Changes to the other files wait with it, since a reload applies all files or none. The mechanism is described in #449; the public docs say only what an application needs. - A configured file that does not exist contributes no overrides, so a file can be created later and deleting a file removes its overrides; a file that exists but cannot be read or parsed fails that reload and keeps the last good overrides, with a logged failure and a retry; a rewrite with identical content is not reapplied; the initial load completes before the client constructor returns. A `flagValues` entry expands into a flag that is on and serves the value by fallthrough, so the evaluation reports the FALLTHROUGH reason kind. Every applied change is logged at Info with the overrides in effect and what each file supplied, and the reloader's log lines for this source, including the hold's debug lines, carry a `FileOverrideSource` prefix. The `override_source` docs say how the format is chosen, that files must be UTF-8, that comments and repeated keys in JSON depend on the application's `json` gem, that files can be rewritten in place, how to remove a file's overrides, that an empty JSON file is not a valid document, and that replacing a YAML file in one operation avoids briefly applying a partly written file. ## Testing - Specs for the builder (defaults, absolute paths, every invalid option, `listen` requirement, poll interval clamping), the initial load (merge, fallthrough-form expansion, YAML, missing file, all files missing, malformed file, duplicate keys under both handlings), the Info log format, polling change detection (change, appearance, deletion, malformed edit with recovery, identical rewrite, stop, stop before start), watching change detection (change, appearance, deletion), and a client-level check of serving and reloading overrides through `LDClient`. - The specs rewrite override files in place with real, deliberately slow writes. End-to-end specs check that the source never supplies a snapshot without the override, and that a client never serves the LaunchDarkly value, while a JSON or YAML file is rewritten in place with a 300 ms pause, with polling and watching change detection; also for a YAML file whose leading comment is written before the pause, for five rewrites about a second apart with the default timing, for a JSON file and a YAML file that stay empty, and for files that are UTF-16 or not valid UTF-8, at startup and at runtime. - The in-place rewrite handling was reviewed in eight rounds as #479 (multi-agent and Bugbot reviews); see #449 for the mutation check (67 mutants, 60 killed, 7 equivalent) and the loops (10 runs in a row on Ruby 3.2 and on JRuby 9.4, no failures). - The `flag overrides` suite of sdk-test-harness (3.2.0-alpha.13, built from #515, whose override files are rewritten in place and have no extension) passes against the test service of #454: 79 tests ran, all passed. - Full suite and RuboCop are clean, apart from `can be automatically loaded by Bundler.require`, which needs write access to the system gem directory on the test machine. Each new spec was checked against a deliberate defect in the code it covers. The existing FDv1 and FDv2 file data sources keep their current behavior. This series does not change them; the override feature is additive. [SDK-3249](https://launchdarkly.atlassian.net/browse/SDK-3249) [SDK-3249]: https://launchdarkly.atlassian.net/browse/SDK-3249?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ   Opened from termag  --- > [!NOTE] > **Overview** > Adds **`LaunchDarkly::Integrations::FileData.override_source`** so operators can load **flag and segment overrides from local JSON/YAML files** that take precedence over LaunchDarkly at evaluation time, wired through **`DataSystem::ConfigBuilder#overrides`**. The new **`FileOverrideSource`** reuses the shared **`FileData::Reloader`** (with **`skip_missing_paths`**, **`skip_unchanged`**, polling or optional `listen` watching) and logs applied overrides with a **`FileOverrideSource:`** prefix. > > **`Reloader`** gains a configurable **`log_prefix`** (default `[LDClient]`) and logs unexpected errors directly instead of **`Util.log_exception`**. > > Documentation examples for custom data systems now use **`data_system_config:`** and **`.build`** on **`DataSystem`** builders instead of the old **`data_system:`** shape. > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit 46b384f. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).

…nd the key (#493)  **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) - [ ] I have validated my changes against all supported platform versions (run on Ruby 3.2 only) **Related issues** - Spec: launchdarkly/sdk-specs#288 (Requirements 1.1.1.1, 1.2.8.1 and 1.3.6.2: the override layer never holds a deleted item). - [SDK-3249](https://launchdarkly.atlassian.net/browse/SDK-3249) This PR is stacked on #454 so that the PRs below it do not change. Its base is `rlamb/overrides-ruby-contract-tests`. **Describe the solution you've provided** Before: - The override sink already rejected a snapshot with a deleted flag or segment with `ArgumentError`, before the layer changed. Nothing logged the rejection when a custom source supplied the snapshot after it had started. The message used the internal kind namespace: `the override features entry f is deleted`. - The file override source failed the reload only through that sink check. The log named neither the file nor the kind as users know it: `Unable to load flags: the override features entry f is deleted`. After: - The file override source checks each file as it reads it, before it supplies a snapshot. A file with a flag or segment entry marked as deleted fails the reload in the same way as a file that cannot be parsed: the previous overrides stay, the existing retry applies, and the failure is logged at Error level with the file and the key, for example `[LDClient] FileOverrideSource: Unable to load flags: flag "f" in /path/overrides.json is marked as deleted; remove the entry to remove its override`. The check runs through a new `check_document` option of the shared reloader (`impl/file_data/reloader.rb`), and only the override source sets it. - The sink still raises `ArgumentError` for a snapshot with a deleted flag or segment. It now also logs the rejection at Error level, with "flag" or "segment" and the key: `[LDClient] Rejected an override snapshot, keeping the overrides in effect: override flag "f" is marked as deleted; leave the flag out of the snapshot to remove its override`. The whole snapshot is rejected, the layer is unchanged, and no change notifications are sent. - `deleted: false` is an ordinary definition and still loads. - Public docs: `FileData.override_source` and `OverrideSink#set_overrides` each gain one sentence about entries marked as deleted. The ordinary file data sources (v1 `FileDataSourceImpl` and FDv2 `FileDataSourceV2`) are unchanged on purpose. Rejecting deleted entries there would be a breaking change, which is planned for a later major version. Neither of them uses the shared `impl/file_data` engine. The new specs pin that both of them, and the reloader without a document check, still load entries marked as deleted. Tests added or changed: - `spec/impl/overrides/sink_spec.rb`: a deleted flag, and a deleted segment given as a model object, each reject the whole snapshot. The other entries are not applied, the layer is unchanged, nothing is notified, and the Error log names the kind and the key. Entries with `deleted: false` are accepted. The existing test's message expectations moved into these tests. - `spec/integrations/file_override_source_spec.rb`: a deleted flag fails the initial load, and the log names the file and the key. On a running source, a deleted flag keeps the previous overrides, and the fix is applied. A deleted segment in a YAML file keeps every file's overrides, including a change to the other file, until the segment entry is fixed. `deleted: false` loads. With a client, the override is still served, the log names the file, and the sink's rejection never appears because the source fails the load first. - `spec/impl/file_data/reloader_spec.rb`: a document check that raises fails the load and keeps the last good result. The other files are still checked. Without a check, deleted entries are combined as before. - `spec/integrations/file_data_source_v2_spec.rb`, `spec/integrations/file_data_source_spec.rb`: pins that the data sources still load entries marked as deleted. How I ran them (Ruby 3.2.3): - `bundle exec rspec spec/impl/overrides spec/impl/file_data spec/integrations/file_override_source_spec.rb spec/integrations/file_data_source_v2_spec.rb spec/integrations/file_data_source_spec.rb`: 312 examples, 0 failures. - `bundle exec rspec spec` (database store specs skip by default): 1681 examples, 1 failure. The failure is `spec/launchdarkly-server-sdk_spec.rb:5`, the `Bundler.require` autoload test. Its inline bundler gets `Permission denied` on `/var/lib/gems/3.2.0/bundler.lock` on this machine, so it is a local environment problem and unrelated to this change. - I ran the new specs against the parent commit with only the spec files copied. The 7 behavior tests fail there, and the 5 pins and `deleted: false` tests pass. Two mutants also fail the expected tests: removing the sink's log line, and skipping segments in the file check. - `bundle exec rubocop` on the changed files: no offenses. **Describe alternatives you've considered** - Checking only in the sink: the sink cannot name the file. Under retries, the reloader logs repeats of the same failure at Debug, so the first Error line would still not say which file to fix. - Checking inside `FileData.merge`: merge does not know the file paths, and the ordinary data sources would share it once they move onto the engine. A per-document hook keeps the rule on the override path. - Logging every sink rejection, including an entry without a key: a file with an empty key (`"": ...`) reaches the sink, and the reloader retries every second. An Error line from the sink on each retry would repeat what the reloader already logs once. So only the deleted-item rejection, which the file source never reaches now, is logged by the sink. **Additional context** Separate follow-up, not fixed here: the v1 file data source has its own bug. `LDClient.new` raises `NoMethodError` when a file has an entry marked as deleted, because `dependency_tracker.rb:60` checks `deleted` only on a hash. Line 70 then reads the prerequisites of a deleted model, which are nil. The same happens on `main`. The v1 pin in this PR writes to a data store without an update sink, so it does not touch that path.   Opened from termag [SDK-3249]: https://launchdarkly.atlassian.net/browse/SDK-3249?atlOrigin=eyJpIjoiNWRkNTljNzYxNjVmNDY3MDlhMDU5Y2ZhYzA5YTRkZjUiLCJwIjoiZ2l0aHViLWNvbS1KU1cifQ  --- > [!NOTE] > **Overview** > Adds a **`check_document`** hook to `FileData::Reloader` so each parsed file can be validated before merge; a `MergeError` from the hook fails the reload like a parse error and keeps the last good snapshot. > > The **file override source** wires this to **`reject_deleted_entries`**, which rejects files containing flag or segment entries with `deleted` set (other than false/null), logging errors that name the **file path** and **key**. **Override sink** still rejects full snapshots with deleted items but now uses user-facing "flag"/"segment" wording and **logs an ERROR** when rejecting, so custom sources get visibility too. > > **Public docs** for `FileData.override_source` and `OverrideSink#set_overrides` note that deleted entries fail loads / are rejected. **v1 and FDv2 file data sources** are unchanged and still accept deleted entries (pinned by new specs). > > Reviewed by [Cursor Bugbot](https://cursor.com/bugbot) for commit cbf2a1d. Bugbot is set up for automated code reviews on this repo. Configure [here](https://www.cursor.com/dashboard/bugbot).

kinyoklion force-pushed the rlamb/overrides-ruby-file-source branch from 605d0ab to 5bda436 Compare September 28, 2026 20:36

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from 63dd6c6 to 24a8d56 Compare September 28, 2026 20:36

kinyoklion force-pushed the rlamb/overrides-ruby-file-source branch from 5bda436 to 4287523 Compare October 1, 2026 23:43

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from 24a8d56 to d04deb5 Compare October 1, 2026 23:43

kinyoklion force-pushed the rlamb/overrides-ruby-file-source branch from 4287523 to 703e368 Compare October 3, 2026 00:46

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from d04deb5 to b98adec Compare October 3, 2026 00:46

cursor Bot reviewed Oct 3, 2026

View reviewed changes

kinyoklion force-pushed the rlamb/overrides-ruby-file-source branch from 703e368 to 18d4335 Compare October 3, 2026 01:54

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from b98adec to b249b70 Compare October 3, 2026 01:54

kinyoklion force-pushed the rlamb/overrides-ruby-file-source branch from 18d4335 to d4f7481 Compare October 8, 2026 16:55

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from b249b70 to f4aea05 Compare October 8, 2026 16:55

kinyoklion force-pushed the rlamb/overrides-ruby-file-source branch from d4f7481 to ddada85 Compare October 13, 2026 22:12

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch 2 times, most recently from 3758acf to ca1e973 Compare October 15, 2026 22:25

kinyoklion force-pushed the rlamb/overrides-ruby-file-source branch from d0a8633 to e0adc16 Compare October 16, 2026 21:40

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from ca1e973 to 108dd59 Compare October 16, 2026 21:40

kinyoklion force-pushed the rlamb/overrides-ruby-file-source branch from e0adc16 to 15125ab Compare October 28, 2026 22:18

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from 108dd59 to ad1e465 Compare October 28, 2026 22:18

kinyoklion force-pushed the rlamb/overrides-ruby-file-source branch from 15125ab to 647d385 Compare October 28, 2026 22:41

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from ad1e465 to 704e170 Compare October 28, 2026 22:41

kinyoklion force-pushed the rlamb/overrides-ruby-file-source branch from 647d385 to 357c6ae Compare October 28, 2026 22:53

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from 704e170 to 6330747 Compare October 28, 2026 22:53

cursor Bot reviewed Oct 28, 2026

View reviewed changes

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from 6330747 to 1d45fe4 Compare October 28, 2026 22:58

kinyoklion force-pushed the rlamb/overrides-ruby-file-source branch from 68137e0 to d5a0b9c Compare October 28, 2026 23:28

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from 1d45fe4 to 34cc17c Compare October 28, 2026 23:28

cursor Bot reviewed Oct 28, 2026

View reviewed changes

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from 1cc7623 to 9a7bd2a Compare November 4, 2026 22:55

keelerm84 approved these changes Nov 5, 2026

View reviewed changes

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from 9a7bd2a to 9063605 Compare November 6, 2026 23:47

kinyoklion force-pushed the rlamb/overrides-ruby-file-source branch from cd1861c to 8209864 Compare November 6, 2026 23:47

kinyoklion marked this pull request as ready for review November 6, 2026 23:55

kinyoklion requested a review from a team as a code owner November 6, 2026 23:55

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from 9063605 to 0590126 Compare November 6, 2026 23:56

kinyoklion added 15 commits November 6, 2026 23:58

test: Wait for the events payload without Queue#pop's timeout

52346f1

test: Expect the fallthrough reason for value-only overrides

874ba86

fix: Reject empty and non-string override file paths

bf90e41

fix: Write the log prefix once on the reloader's unexpected error line

776acda

fix: Treat a repeated override file path in different case as a repea…

4e5f6ef

…t on Windows

kinyoklion force-pushed the rlamb/overrides-ruby-file-source branch from 1a9d9db to 46b384f Compare November 6, 2026 23:58

kinyoklion force-pushed the rlamb/overrides-ruby-contract-tests branch from 0590126 to bb7a5ca Compare November 6, 2026 23:58

kinyoklion mentioned this pull request Nov 10, 2026

fix: Fail an override file load on a deleted entry, naming the file and the key #493

Merged

2 of 3 tasks

Base automatically changed from rlamb/overrides-ruby-file-source to feat/overrides November 10, 2026 23:35

kinyoklion merged commit 9c16ac9 into feat/overrides Nov 10, 2026
7 checks passed

kinyoklion deleted the rlamb/overrides-ruby-contract-tests branch November 10, 2026 23:35

Navigation Menu

Repository navigation

feat: Add flag overrides to the contract test service - #454

feat: Add flag overrides to the contract test service#454
kinyoklion merged 15 commits into
feat/overridesfrom
rlamb/overrides-ruby-contract-tests

kinyoklion commented Sep 25, 2026 •

edited by cursor Bot

Loading

Uh oh!

kinyoklion commented Oct 3, 2026

Uh oh!

cursor Bot left a comment •

edited

Loading

Uh oh!

kinyoklion commented Oct 28, 2026

Uh oh!

cursor Bot left a comment •

edited

Loading

Uh oh!

kinyoklion commented Oct 28, 2026

Uh oh!

cursor Bot left a comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

kinyoklion commented Sep 25, 2026 • edited by cursor Bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Uh oh!

kinyoklion commented Oct 3, 2026

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kinyoklion commented Oct 28, 2026

Uh oh!

cursor Bot left a comment • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kinyoklion commented Oct 28, 2026

Uh oh!

cursor Bot left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

kinyoklion commented Sep 25, 2026 •

edited by cursor Bot

Loading

cursor Bot left a comment •

edited

Loading

cursor Bot left a comment •

edited

Loading