[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}

SDK-3493

---

Note

Overview
The .NET server contract test service now implements harness scenarios for file and test data sources, including optional persistence to the data store.

Harness JSON can configure a file initializer or synchronizer (paths plus optional persist); synchronizers use auto-reload on file changes. A testData synchronizer seeds flags with ValueForAll, and the new updateTestData command updates a flag on the single registered TestData instance. Invalid configs (empty file paths, duplicate testData, missing test data on update) fail fast.

BuildSdkConfig / CreateSynchronizer are instance methods so each client keeps its TestData reference for commands. The status endpoint advertises file-data-source, test-data-source, and data-source-persist-opt-in.

^{Reviewed by Cursor Bugbot for commit 165061a. 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.}