[kinyoklion]

Summary

The test harness gains tests that a file data source and a test data source do not write their data to a persistent store, and that they do when they request it (launchdarkly/sdk-test-harness#537). This change lets the server SDK's contract test service run them, on dotnet-server-sdk-v9, where TestData is not persisted by default (#390).

• A file entry in dataSystem.initializers or dataSystem.synchronizers configures FileData.DataSource() with the given file paths. As a synchronizer it reloads the files when they change (AutoUpdate(true)).
• A testData synchronizer configures a TestData source whose flags each serve one value to every context (ValueForAll), and the updateTestData command changes one of its flags. A configuration may have one testData synchronizer, and no testData initializer, as the service spec says.
• A file entry needs at least one file path, and updateTestData needs a flag key; the service rejects the configuration or the command otherwise.
• persist: true on either entry calls ShouldPersist(true).
• The service advertises file-data-source, test-data-source, and data-source-persist-opt-in.

BuildSdkConfig and CreateSynchronizer become instance methods, so that the client entity keeps its test data source for the command.

Dependencies

• This branch is based on feat: Let each data source decide whether FDv2 writes its data to a persistent store #390, which adds ShouldPersist to FileDataSourceBuilder and TestData.
• The new tests are in the persistence suite, so they run only with the persistent store support and the CI changes of ci: Run the persistence contract tests #392. Until both land, the new capabilities have no effect in CI.
• There is no main version. On main, TestData is persisted by default, so the test data tests, which expect it not to be, would fail there.

Testing

Against a local merge of this branch and #392, with Redis, DynamoDB local, and Consul in Docker, the harness branch's data source persistence tests pass for all three stores.

To check that the tests catch the defects they target, defects were put into the SDK one at a time, and each failed the tests that target it for every store: the write-through store's persistence check removed; upserts always persisted, as Java's FDv1 adapter does; the recovery write back done whatever the persistence indicator; persisting everything once anything was persisted; and the store mode ignored for data that requests persistence.

_{Opened from termag}

---

Note

Overview
The .NET server SDK contract test service now implements harness scenarios for file and test data sources and for opt-in persistence to the FDv2 data store.

Harness JSON can configure a file block on data-system initializers (one-shot load) or synchronizers (reload on change via AutoUpdate). A testData synchronizer seeds flags with ValueForAll, and the new updateTestData command mutates a single flag on that source. Optional persist: true maps to ShouldPersist(true) on both source types; invalid configs (missing file paths, duplicate test-data synchronizers, or updateTestData without a test source) fail fast.

BuildSdkConfig / synchronizer wiring are instance methods so each client keeps a handle to its lone TestData instance for runtime updates. The service advertises file-data-source, test-data-source, and data-source-persist-opt-in so the harness can run the new persistence suite.

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

[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 e8c9f4a. Configure here.}