[kinyoklion]

Summary

In the FDv2 data system with a persistent store in read-write mode, the SDK wrote the data of every initializer and synchronizer to the store, and wrote all of the memory store back to it after an outage. A file data source used as an initializer or synchronizer therefore replaced the LaunchDarkly data in a shared Redis, DynamoDB, or Consul store, on start, on every reload, and again on every store recovery.

The data system spec requires each data source to say whether its data may be persisted, and the SDK to mirror only that data: requirement 1.1.7 for initializers and 1.2.8 for synchronizers (specs/DATASYSTEM-data-system/v2/README.md). Its example is the file initializer, which does not persist. The decision is not based on the payload selector, because the FDv1 fallback synchronizer has no selector and its data must still be persisted (the spec's definition of a basis notes that neither a file data source nor the FDv1 fallback synchronizer can provide one).

The Java SDK is the complete reference implementation, and this change follows its design, with one difference described below.

How it works

• ChangeSet and FullDataSet carry an internal persist flag. It is stored inverted, so that a defaulted struct, or one built with an existing constructor, means "persist". The public API of both types is unchanged.
• WriteThroughStore writes a full data set or a change set to the persistent store only if its flag is set. Data that is not persisted still goes to the memory store, which becomes the store that evaluations read from, as before.
• InMemoryDataStore remembers the flag of the latest full or partial change set and returns it from ExportAll. Like the transactional persistent store spec (requirement 1.4.3.2), it tracks a single, most recent indicator, not one per item.
• PersistentStoreWrapper.PollAvailabilityAfterOutage skips the write when the exported data must not be persisted. The store still reports that it has recovered, and keeps its contents.
• DataStoreSorter keeps the flag when it sorts a data set or change set.

How a data source states its flag

FDv2 polling and streaming create their change sets with the flag set.

Every other source is an FDv1-style source run through DataSourceUpdatesV2ToV1Adapter. An FDv1 Upsert call has no data set that could carry a flag. So the data system reads the flag from the source's configurer each time it builds the source, through the internal interface IDataSourcePersistence, and gives it to the adapter. A configurer that does not implement the interface is persisted.

The file and test data sources also put the flag on the full data sets they deliver, so that their data stays out of the store when an application's own configurer wraps theirs and hides the interface. The adapter persists a full data set only if both the configurer and the data set allow it, and an upsert takes the flag of the last full data set, the data it changes.

This is where the change differs from Java. Java's adapter copies the flag from the full data set but always sets it on upserts, so a Java TestData configured with shouldPersist(false) keeps its initial data out of the store but writes every later update to it. After one update the memory store's flag says "persist", so the next store recovery writes the initial data as well.

Defaults

Source	Persisted
FDv2 polling and streaming	yes
FDv1 fallback synchronizer (DataSystemComponents.FDv1Polling())	yes
A custom data source	yes, as before
FileData.DataSource()	no; FileDataSourceBuilder.ShouldPersist(true) opts in
TestData	yes, as before; TestData.ShouldPersist(false) opts out

The FDv1 data system is unchanged: its data store, persistent or not, receives all data, including the file data source's. The flag is read only by the FDv2 data system.

Behavior change: an application that uses the file data source as an FDv2 initializer or synchronizer with a read-write persistent store no longer has the file data written to the store. FileDataSourceBuilder.ShouldPersist(true) restores that.

Mixed sequences

• A file initializer followed by a persisted synchronizer's basis: the basis is written to the store and replaces whatever the store held, and a recovery after it writes the memory store.
• A delta whose flag differs from the basis it applies to: the write-through store writes or skips each change set by its own flag, and recovery follows the flag of the latest change set, as the spec says. A persisted delta can only follow a basis that was not persisted if a source sends a delta without a basis of its own. A file source never sends deltas, TestData starts with a full data set, and an FDv2 synchronizer that follows a basis without a selector (the file and test data sources provide none) requests a full transfer.

Testing

• FDv2DataSystemPersistenceTest runs real clients against a mock persistent store, for each case:
  • A file initializer is not written.
  • A file synchronizer's reload is not written.
  • File data with ShouldPersist(true) is written.
  • TestData is written by default, initial data and updates.
  • TestData with ShouldPersist(false) is written neither for its initial data nor for an update.
  • A custom FDv1-style data source is written.
  • The FDv1 fallback synchronizer's data is written.
  • A persisted synchronizer basis after a file initializer is written, and the file data is not; the store's Init count shows it, because the mock store's Init replaces all of its data.
  • A file data source or TestData behind an application's own wrapping configurer is not written.
  • The FDv1 data system with a file data source still writes to the store.
• Unit tests for the write-through store, the memory store's flag of the latest change set, recovery with data that must not be persisted and with persisted data that replaced it, the adapter, the sorter, and the flag on FDv2 polling and streaming change sets.
• To check that the tests detect the defects they target, each of thirteen parts of the fix was reverted on its own, and every reversion failed at least one test:
  • The write-through check.
  • The adapter's upsert flag, reverted to Java's behavior.
  • The recovery skip.
  • The memory store's flag for partial payloads.
  • Reading the configurer's flag.
  • The sorter.
  • The TestData flag.
  • The file data default.
  • The flag on the file data source's data set.
  • The flag on TestData's data set.
  • The adapter's use of the data set's flag.
  • The upsert's use of the last data set's flag.
  • The memory store's update of the flag on a partial payload.
• The full server SDK test suite passes on net8.0 (1697 tests). The SDK builds for netstandard2.0, net462, and net8.0.

The contract tests do not cover this. The harness persistence suites have no test of file or test data, and this repository runs them with enable_persistence_tests: 'false'; the contract test service has no persistent store support. A separate change enables them, and the harness gains tests of these cases.

#390 makes the same change on dotnet-server-sdk-v9, where TestData is not persisted by default.

Found in review, not changed here

A multi-agent review of this change found three gaps in code it does not change. Java has the same three:

• TXNS 1.4.3.1: with an infinite cache TTL, a store recovery before the first payload takes the cache-based branch of PollAvailabilityAfterOutage and writes an empty data set. Consul's Init deletes every key under the prefix that is not in the data, so this empties a shared Consul store.
• TXNS 1.3.5: when a shared store rejects a delta item because it already holds that version or a newer one, WriteThroughStore stops applying the rest of the delta and throws, so the SDK reports a store error and skips the flag change events.
• TXNS 1.4.3.3: the recovery write back is not serialized with concurrent updates, so a newer item that this SDK writes during it can be replaced by the older snapshot.

_{Opened from termag}

---

Note

Overview
The FDv2 data system no longer blindly mirrors every initializer/synchronizer (and post-outage memory snapshots) into a read-write persistent store. FullDataSet and ChangeSet now carry an internal ShouldPersist flag (default persist), and WriteThroughStore, InMemoryDataStore export, and PersistentStoreWrapper recovery honor it so file/test data can stay memory-only while LaunchDarkly traffic still writes through.

Source configuration: new internal IDataSourcePersistence; FileDataSourceBuilder.ShouldPersist defaults off (opt-in to write file loads/reloads); TestData.ShouldPersist defaults on (opt out with false). File and test sources also attach the flag on full payloads so wrapped configurers cannot accidentally persist. DataSourceUpdatesV2ToV1Adapter ANDs configurer + dataset flags on inits and ties FDv1-style upserts to the last full dataset flag (differs from Java for TestData with persist false).

Behavior change: file data used as an FDv2 initializer/synchronizer with a shared store no longer replaces Redis/Dynamo/Consul data unless ShouldPersist(true). FDv1 ConfigurationBuilder.DataSource path unchanged.

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

[kinyoklion]

bugbot review

[kinyoklion]

bugbot review

[cursor]

Stale Bugbot comment from a previous run.

[kinyoklion]

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 982d5c9. Configure here.}