chore: Add FDv2 Data System

[kinyoklion]

Note

Adds the FDv2 data system with a new transactional update API, composite source orchestration, write-through store, and integrated streaming/polling with selector support, plus extensive tests.

• FDv2 Data System (core):
  • Introduces IDataSourceUpdatesV2 (transactional updates API) and adapts legacy sources via DataSourceUpdatesV2ToV1Adapter.
  • Adds FDv2DataSystem, WriteThroughStore (memory+persistent, selector-aware), and SelectorSourceFacade.
  • Wires LdClient to use FDv2 when Configuration.DataSystem is set.
• Composite source orchestration:
  • Refactors to CompositeSource using IDataSourceObserver, ObservableDataSourceUpdates, and DataSourceUpdatesSanitizer (V2).
  • Replaces fan-out/IActionApplier with observer pattern and disableable sinks; updates SourceFactory/ActionApplierFactory signatures.
• FDv2 data sources:
  • Builds FDv2 streaming/polling with selector support and transactional applies.
  • FDv2DataSource composes initializers/synchronizers with fallback/blacklist logic and timed recovery.
  • Streaming: ignore unknown events (debug log), exposes handled event list.
• Tests & support:
  • Extensive new/updated unit tests for composite, FDv2 streaming/polling, and data flow; contract-test suppressions added.
  • Adds test visibility in AssemblyInfo.

^{Written by Cursor Bugbot for commit dd9ec86. This will update automatically on new commits. Configure here.}

[kinyoklion]

bugbot review

[cursor]

Bug: Silent failure when applying to legacy persistent store

When ApplyToLegacyPersistence returns false (indicating a failure to write to a legacy non-transactional persistent store), the failure is silently ignored. The data has already been written to the memory store at this point, so the memory and persistent stores become inconsistent. On SDK restart, the persistent store would have stale data. The failure result from ApplyToLegacyPersistence is not propagated or handled, leaving only a TODO comment.

 

[kinyoklion]

This will be addressed later.

[cursor]

Bug: Task hangs forever if disposed during StartCurrent

The StartCurrent method checks _disposed outside the lock, then creates a TaskCompletionSource and enqueues an action to complete it. If Dispose is called between the check and the action being processed, InternalDispose clears _pendingActions, orphaning the TaskCompletionSource. The returned Task will never complete, causing any caller awaiting it to hang indefinitely. The EnqueueAction method doesn't check disposal state before enqueueing, allowing actions to be added and then immediately discarded.

pkgs/sdk/server/src/Internal/DataSources/CompositeDataSource/CompositeSource.cs#L239-L282

dotnet-core/pkgs/sdk/server/src/Internal/DataSources/CompositeDataSource/CompositeSource.cs

Lines 239 to 282 in 7af16ce

	/// </summary>
	public Task<bool> StartCurrent()
	{
	if (_disposed)
	{
	return Task.FromResult(false);
	}
	var tcs = new TaskCompletionSource<bool>();
	EnqueueAction(() =>
	{
	IDataSource dataSourceToStart;
	lock (_lock)
	{
	TryFindNextUnderLock();
	dataSourceToStart = _currentDataSource;
	}
	if (dataSourceToStart is null)
	{
	// No sources available.
	tcs.SetResult(false);
	return;
	}
	// Start the source asynchronously and complete the task when it finishes.
	// We do this outside the lock to avoid blocking the queue.
	_ = Task.Run(async () =>
	{
	try
	{
	var result = await dataSourceToStart.Start().ConfigureAwait(false);
	tcs.TrySetResult(result);
	}
	catch (Exception ex)
	{
	tcs.TrySetException(ex);
	}
	});
	});
	return tcs.Task;
	}

pkgs/sdk/server/src/Internal/DataSources/CompositeDataSource/CompositeSource.cs#L94-L121

dotnet-core/pkgs/sdk/server/src/Internal/DataSources/CompositeDataSource/CompositeSource.cs

Lines 94 to 121 in 7af16ce

	private void InternalDispose(DataSourceStatus.ErrorInfo? error = null)
	{
	// When disposing the whole composite, we bypass the action queue and tear
	// down the current data source immediately while still honoring the same
	// state transitions under the shared lock. Any queued actions become no-ops
	// because there is no current data source
	// been disconnected.
	lock (_lock)
	{
	// cut off all the update proxies that have been handed out first
	_disableableTracker.DisablePreviouslyTracked();
	// dispose of the current data source
	_currentDataSource?.Dispose();
	_currentDataSource = null;
	// clear any queued actions and reset processing state
	_pendingActions.Clear();
	_isProcessingActions = false;
	_currentEntry = default;
	_disposed = true;
	}
	// report state Off directly to the original sink, bypassing the sanitizer
	// which would map Off to Interrupted (that mapping is only for underlying sources)
	_originalUpdateSink.UpdateStatus(DataSourceState.Off, error);
	}

 

---

[cursor]

Bug: Exception swallowing can cause Start() to hang indefinitely

The ProcessQueuedActions method catches and swallows all exceptions from enqueued actions. When StartCurrent() enqueues an action that calls TryFindNextUnderLock(), if the data source factory or action applier factory throws an exception, it gets silently caught. The TaskCompletionSource is never completed (no SetResult or SetException), causing the returned Task from Start() to hang indefinitely. Any caller awaiting Start() would block forever if factory initialization fails.

pkgs/sdk/server/src/Internal/DataSources/CompositeDataSource/CompositeSource.cs#L177-L186

dotnet-core/pkgs/sdk/server/src/Internal/DataSources/CompositeDataSource/CompositeSource.cs

Lines 177 to 186 in dd9ec86

	// the next action to prevent one failure from stopping all processing.
	try
	{
	action();
	}
	catch
	{
	// Continue processing remaining actions even if one fails
	// TODO: need to add logging, will add in next PR
	}

 

---