Repository navigation
Conversation
The test service no longer maps the top-level streaming, polling and persistentDataStore settings that harness v2 sends, and no longer reports the filtering, filtering-strict and retry-conformance-fdv1 capabilities. Harness v3 sends a dataSystem block for every test. A client with no dataSystem block gets a data system with no sources, as LDD mode did. CI and the Makefile run harness v3 only.
The client now always uses the FDv2 data system. When data_system_config is nil, it uses DataSystem.default. Removed config options: stream, use_ldd, poll_interval, initial_reconnect_delay, base_uri, stream_uri, feature_store, data_source, cache_store, payload_filter_key and data_source_update_sink. Use the data system builders in their place: DataSystem.persistent_store or DataSystem.daemon for a persistent store, and the polling and streaming builders for URIs and intervals. Removed classes and methods: the v1 TestData and its FlagBuilder, FileData.data_source, InMemoryFeatureStore, the FDv1 data source mixin in Interfaces::DataSource, and the Interfaces::DataSource::UpdateSink and Interfaces::DataStore::UpdateSink interfaces. Use TestDataV2 and FileData.data_source_v2. LaunchDarkly::Integrations now loads TestDataV2. The SDK key is required unless the client is offline, or events are disabled and no data source connects to LaunchDarkly. Daemon mode is a data system with no initializers or synchronizers. With events disabled it reports initialized and a fork does not break it, as LDD mode did. The diagnostic init event no longer reports customBaseURI, customStreamURI, pollingIntervalMillis, streamingDisabled or usingRelayDaemon. The FDv2 fields are still to be decided before 9.0. The FDv1 fallback that FDv2 uses stays. UnexpectedResponseError moves to Impl::DataSystem with the FDv2 polling code.
The FDv2 polling builder and the FDv1 fallback polling builder replace a poll interval below 30 seconds with 30 seconds and log a warning. The removed poll_interval config option had the same minimum. Without it, a small or zero interval polls LaunchDarkly in a tight loop.
The polling, streaming and FDv1 fallback sources send the SDK key whatever their base URI, so they need it even when they connect to a Relay Proxy. The old name said that they connect to LaunchDarkly.
- The FDv2 and FDv1 fallback HTTP polling requesters: request headers, ETag and 304, gzip, the basis parameter, error status, response headers and proxy. - PollingDataSource#stop ends a long interval wait. - FileData v2: YAML with a Ruby object and file paths with shell metacharacters do not run code, reload without the listen gem, an initial sync failure, full flags from flagValues, and evaluation through LDClient. - Every FlagBuilderV2 and FlagRuleBuilderV2 method. - Streaming sync error paths, and the environment ID through the real on_connect handler in place of a copy of its logic. - The FeatureStoreClientWrapperV2 availability poller. - FDv2 data availability: CACHED, DEFAULTS and daemon mode. - StatusProviderV2 listener notifications.
…mk/SDK-3474/remove-fdv1
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.
fix: Enforce the 30 second minimum poll interval in the polling builders
Summary
The client now always uses the FDv2 data system. When data_system_config
is nil, it uses DataSystem.default.
Removed config options: stream, use_ldd, poll_interval,
initial_reconnect_delay, base_uri, stream_uri, feature_store,
data_source, cache_store, payload_filter_key and data_source_update_sink.
Use the data system builders in their place: DataSystem.persistent_store
or DataSystem.daemon for a persistent store, and the polling and
streaming builders for URIs and intervals.
Removed classes and methods: the v1 TestData and its FlagBuilder,
FileData.data_source, InMemoryFeatureStore, the FDv1 data source mixin
in Interfaces::DataSource, and the Interfaces::DataSource::UpdateSink
and Interfaces::DataStore::UpdateSink interfaces. Use TestDataV2 and
FileData.data_source_v2. LaunchDarkly::Integrations now loads
TestDataV2.
The SDK key is required unless the client is offline, or events are
disabled and no data source connects to LaunchDarkly. Daemon mode is a
data system with no initializers or synchronizers. With events disabled
it reports initialized and a fork does not break it, as LDD mode did.
The diagnostic init event no longer reports customBaseURI,
customStreamURI, pollingIntervalMillis, streamingDisabled or
usingRelayDaemon. The FDv2 fields are still to be decided before 9.0.
The FDv1 fallback that FDv2 uses stays. UnexpectedResponseError moves to
Impl::DataSystem with the FDv2 polling code.
The FDv2 polling builder and the FDv1 fallback polling builder replace
a poll interval below 30 seconds with 30 seconds and log a warning. The
removed poll_interval config option had the same minimum. Without it, a
small or zero interval polls LaunchDarkly in a tight loop.
The test service no longer maps the top-level streaming, polling and
persistentDataStore settings that harness v2 sends, and no longer reports
the filtering, filtering-strict and retry-conformance-fdv1 capabilities.
Harness v3 sends a dataSystem block for every test. A client with no
dataSystem block gets a data system with no sources, as LDD mode did.
CI and the Makefile run harness v3 only.
ETag and 304, gzip, the basis parameter, error status, response
headers and proxy.
metacharacters do not run code, reload without the listen gem, an
initial sync failure, full flags from flagValues, and evaluation
through LDClient.
on_connect handler in place of a copy of its logic.
Note
Overview
Breaking: the Ruby SDK now only runs the FDv2 data path.
LDClientalways buildsDataSystem.defaultwhendata_system_configis omitted, and drops the entire FDv1 layer (legacy stream/poll processors,InMemoryFeatureStore, store wrappers, file/test data v1,Interfaces::DataSource::UpdateSink, etc.).Config & integrations: top-level options like
stream,use_ldd,poll_interval,base_uri/stream_uri,feature_store,data_source,cache_store, andpayload_filter_keyare removed—callers must useDataSystembuilders (persistent_store,daemon, streaming/polling builders,FileData.data_source_v2,TestDataV2). SDK key rules, fork warnings, andinitialized?semantics change to match “no remote sources unless configured.”Behavior & tooling: FDv2 polling builders clamp sub-30s poll intervals (with warnings), move
UnexpectedResponseErroralongside FDv2 polling, trim diagnostic init fields tied to FDv1, and update contract tests/CI/Makefile to harness v3 only with slimmer advertised capabilities.Reviewed by Cursor Bugbot for commit c7a8ee3. Bugbot is set up for automated code reviews on this repo. Configure here.