Skip to content

Conversation

@jsonbailey
Copy link
Contributor

@jsonbailey jsonbailey commented Dec 9, 2025

Note

Replaces legacy data-source/store wiring in LDClient with FDv1 DataSystem and updates client to use its store, status providers, and broadcasters.

  • DataSystem (impl/data_system/fdv1.rb):
    • Add FDv1 implementation wiring v1 data sources/stores behind a unified interface.
    • Wrap original config.feature_store in FeatureStoreClientWrapper (avoid nested wrapping on postfork) and expose status providers/broadcasters/update sinks.
    • Manage processor lifecycle (start/stop), executor, and compute data availability/target; log when streaming is disabled (polling).
  • Core (ldclient.rb):
    • Initialize and use FDv1 for store access (@data_system.store), flag change broadcaster, and data/data-store status providers.
    • Simplify startup/shutdown and postfork by delegating to @data_system; remove legacy data source plumbing.
    • Update initialized? to compare data_availability vs target_availability.
    • Adjust SDK key nil validation to allow LDD or custom data source without events.
    • Update flag evaluation and all_flags_state to read from @data_system.store.
  • Tests (spec/impl/data_system/fdv1_spec.rb):
    • Add comprehensive specs for store wrapping behavior, processor selection (streaming/polling/offline/LDD/custom), lifecycle, availability states, and diagnostic accumulator propagation.

Written by Cursor Bugbot for commit ff845d5. This will update automatically on new commits. Configure here.

@jsonbailey jsonbailey requested a review from a team as a code owner December 9, 2025 18:50
# @return [Array<EvaluationDetail, [LaunchDarkly::Impl::Model::FeatureFlag, nil], [String, nil]>]
#
def variation_with_flag(key, context, default)
private def variation_with_flag(key, context, default)
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The file used a mix of per method private and all methods after the declaration on line 717 of the original file. Moving to defining per method.

# so we're not connecting to any LD services).
if !config.offline? && sdk_key.nil?
# SDK key can be nil only if using LDD or custom data source with events disabled
if config.send_events || (!config.use_ldd? && config.data_source.nil?)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This conditional doesn't make sense to me.

The SDK key is required if:

  1. We are sending events, or
  2. We aren't in daemon mode AND we don't have a data source?

If we aren't in daemon mode, then we should have a data source, and that's when an SDK key is required. If there isn't a data source, what is the key for?

#
def initialized?
@config.offline? || @config.use_ldd? || @data_source.initialized?
@data_system.data_availability == @data_system.target_availability
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we sure these lines are equivalent given our previous discussions about this? I can't remember exactly where we landed on that.

# @return [LaunchDarkly::Interfaces::DataStore::StatusProvider]
#
attr_reader :data_store_status_provider
def data_store_status_provider
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You could also make these delegators if you wanted to tighten the syntax up some. It would be something like:

require 'forwardable'

# ...

extend Forwardable
def_delegators :@data_system, :data_store_status_provider, :data_source_status_provider

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants