Repository navigation
Conversation
The FDv2 streaming and polling requests, and the FDv1 fallback polling request, no longer send the filter query parameter. FDv2 already logged that payload filtering was unsupported and that the payload_filter_key option had no effect, but the requests still sent it. The behavior now matches the warning. The FDv1 data system keeps its payload filter support until the FDv1 removal deletes it. The contract tests no longer map the payloadFilter data system setting. The filtering capabilities stay, because only harness v2 tests them, against FDv1.
TestDataV2 gains use_preconfigured_flag, and FlagBuilderV2 gains migration_settings, sampling_ratio, exclude_from_summaries and a nested FlagMigrationSettingsBuilder. The v1 TestData has all of these, and v9 removes v1 TestData with the FDv1 data system, so TestDataV2 must cover them first. A preconfigured flag keeps its own version, as in v1 TestData, because tests use specific versions to check the evaluation and event output. A flag that replaces an existing flag gets the next version. A preconfigured flag also discards any stored builder for its key, so a later flag call starts from a new builder.
The shared spec config now gives the client an FDv2 data system with no sources, in place of the FDv1 null data source. Specs that need data use TestDataV2 as a synchronizer, and specs that need a persistent store use a hash-backed MockFeatureStore through the data system config. The end-to-end and environment ID specs poll the FDv2 endpoint with an FDv2 payload. On a 401, FDv2 turns the data source off at once and does not retry, so those specs now expect OFF, a single request and no full start wait, in place of the FDv1 retry behavior. The tracker specs use the V2 flag builder. The FDv2 store specs gain the flag change cases that only the FDv1 data source specs covered: flags that a full data set adds or removes, a deleted prerequisite, and a removed dependency. The nil SDK key and use_ldd fork specs still use FDv1 options, because they test FDv1 logic in LDClient. They change with that logic when FDv1 is removed.
…rder use_preconfigured_flag and use_preconfigured_segment now convert the input to a new hash with symbol keys at every level, check it, and raise ArgumentError for an input that is not a valid flag or segment: nil or another type, a missing or empty key, a version that is not an integer, malformed JSON, or a data model error. Before, a hash parsed from JSON kept string keys below the top level and evaluated wrongly, and a malformed item was accepted and later made the whole initial data set fail to load while the data source reported VALID. Both methods also accept a JSON string, as v1 TestData did, and store a copy, so later changes to the caller's object have no effect. A preconfigured flag now keeps a provided version that is greater than the version of the flag it replaces, and otherwise gets the next version. This matches Go's TestDataV2 and the test data source spec, which requires the increment only when the provided version is not greater. Version 0 on a new flag becomes 1. update, use_preconfigured_flag and use_preconfigured_segment now hold a mutex across the change and its delivery to the data source instances. Before, two concurrent changes could reach an instance in the opposite order to the one in which they were made.
The previous commit normalized a preconfigured flag or segment with a JSON round trip. JSON.generate calls to_s on a value it cannot encode, so a Set, a Time or another object became a string with no error. A segment whose included keys were a Set then failed to match. NaN, Infinity, and a hash with the same key as a string and a symbol raised JSON::GeneratorError in place of ArgumentError. The item is now copied value by value. A Set becomes an array and a symbol value becomes a string, as in JSON. Any other value that JSON cannot hold, a value that is not finite, a hash key that is not a string or symbol, a repeated key, and nesting deeper than 100 levels raise ArgumentError. The delivery order spec now has a deadline for the first thread and always releases it, so a failure cannot hang the suite.
…r update FlagRuleBuilderV2#build put the builder's own clause array into the built flag. A rule builder that the test kept after update could then add clauses to the stored flag. This changed what later clients received without a version change or a delivered update. The build now copies each clause and its values.
fix: Enforce the 30 second minimum poll interval in the polling builders
…-on-fdv2 # Conflicts: # spec/integrations/test_data_v2_spec.rb
…ng spec The invalid stream event fix moved the INVALID_DATA status from on_event to on_error. The FDv1 removal added a spec that expected on_event to report it. The spec now passes the raised error to on_error, as the SSE client does.
The FDv2 file source yields its initial data before it starts the poller, and the poller reads the first modification times when it starts. On a slow runner the spec changed the file before the poller started, so the poller saw no change. The spec now waits until the poller exists.
With FDv1 removed, the FDv2 names no longer need a V2 suffix. TestDataV2 is now TestData, FlagBuilderV2 is now FlagBuilder, FlagRuleBuilderV2 is now FlagRuleBuilder, and FileData.data_source_v2 is now FileData.data_source. The test data require path is now ldclient-rb/integrations/test_data. The internal FDv2 classes and files lose the suffix too: StatusProviderV2, FeatureStoreClientWrapperV2, InMemoryFeatureStoreV2, FileDataSourceV2, FileDataSourcePollerV2 and TestDataSourceV2. The polling, streaming and file data sources report their names without the suffix. FDv2 and ProtocolV2 name the protocol version, so they stay. The data_system_config option is now data_system, which the YARD examples already used. FlagBuilder#key is public again, as it was in the v1 FlagBuilder.
…mk/SDK-3530/drop-v2-suffix # Conflicts: # spec/integrations/file_data_source_spec.rb
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
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 47de2de. Configure here.
This branch has not been deployed
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.
With FDv1 removed, the FDv2 names no longer need a V2 suffix. TestDataV2
is now TestData, FlagBuilderV2 is now FlagBuilder, FlagRuleBuilderV2 is
now FlagRuleBuilder, and FileData.data_source_v2 is now
FileData.data_source. The test data require path is now
ldclient-rb/integrations/test_data.
The internal FDv2 classes and files lose the suffix too:
StatusProviderV2, FeatureStoreClientWrapperV2, InMemoryFeatureStoreV2,
FileDataSourceV2, FileDataSourcePollerV2 and TestDataSourceV2. The
polling, streaming and file data sources report their names without the
suffix. FDv2 and ProtocolV2 name the protocol version, so they stay.
The data_system_config option is now data_system, which the YARD
examples already used.
FlagBuilder#key is public again, as it was in the v1 FlagBuilder.
Note
Overview
This is a breaking cleanup now that FDv1 is gone: public and internal types lose the
V2suffix, and client configuration uses a shorter option name.Configuration:
LaunchDarkly::Configaccepts:data_systeminstead of:data_system_config(accessordata_system); contract tests and docs/examples pass the built data system the same way.Public integrations:
TestDataV2→TestData(and buildersFlagBuilder,FlagRuleBuilder);Integrations::FileData.data_sourcereplacesdata_source_v2;FlagBuilder#keyis public again (replacing the private_keyusage inTestData#update).Internal FDv2 stack: implementation classes are renamed without the suffix (e.g.
StatusProvider,FeatureStoreClientWrapper,InMemoryFeatureStore,FileDataSource,TestDataSource, polling/streaming data source names and log strings).FDv2/ProtocolV2names are unchanged.Specs and requires are updated to match; no intended behavior change beyond the renames.
Reviewed by Cursor Bugbot for commit 07cb411. Bugbot is set up for automated code reviews on this repo. Configure here.