[kinyoklion]

Summary

The server SDK's contract test service had no persistent store support: the data system store configuration in SdkClientEntity.cs was commented out with a TODO about the store packages, and the FDv1 persistentDataStore configuration was not handled. CI therefore ran both harness versions with enable_persistence_tests: 'false'. This change makes the service drive real Redis, DynamoDB, and Consul stores and runs the persistence suites in CI.

It is separate from the persistence fix in #390 (and #389 on main), which these tests do not cover yet; the harness gains tests for that behavior in a separate change.

Test service

• The FDv2 dataSystem.store and storeMode configuration (harness v3) and the FDv1 top-level persistentDataStore configuration (harness v2) build the store with Components.PersistentDataStore, with the requested prefix and cache mode.
• An FDv1 configuration with a store and no streaming, polling, or service endpoint configuration runs in daemon mode (Components.ExternalUpdatesOnly), which the v2 suite expects. Without this, the client tried to reach LaunchDarkly and failed to initialize.
• An empty prefix means the store's default prefix, and a store configuration without a DSN is rejected.
• The Redis and DynamoDB clients fail fast (500 ms timeouts, no DynamoDB retries), as the store recovery tests require. The Consul client does not retry.
• The service advertises persistent-data-store-redis, persistent-data-store-dynamodb, persistent-data-store-consul, and persistent-data-store-recovery.
• The service already takes its port as an optional first argument; CI now passes one. Its default stays 8000.

Building against the local SDK

The store projects in pkgs/ reference the published LaunchDarkly.ServerSdk package, so a reference to them would bring a second copy of the SDK into the service. Instead, a small project per store under contract-tests/Stores/ compiles that store's sources against the SDK project, with the same client library and version range as the store's own project. There is one project per store because the Redis and DynamoDB stores share internal type names. The store projects themselves are not changed, and neither are their packages or their builds.

On this branch the SDK is 9.0.0-alpha, outside the stores' published range ([8.0.0, 9.0.0)); the stores build and pass against it from their sources.

CI

• .github/actions/contract-tests gains enable_persistence_tests (default false) and test_service_port (default 8000). With persistence enabled, it starts the stores with launchdarkly/gh-actions/actions/persistent-stores, waits until they accept connections and Consul has a leader, and enables the tests in both harness runs.
• The server SDK workflow enables the persistence tests on the Linux runner only, where the stores start in Docker, and passes port 9000 on every runner: the harness expects DynamoDB on port 8000, the service's default. The client SDK workflow uses the same action with the default port, because its test service always listens on 8000.

Suppressed tests

The persistence suites found three pre-existing defects in the store integrations. They are suppressed with a comment in each suppression file. The harness reads every non-blank line as a test ID, so a line that starts with # matches no test.

1. A deleted flag is stored without a "key" property: {"version":N,"deleted":true}, from the ItemDescriptor serializer in DataStoreTypes.cs (Redis and Consul store that string), or as the placeholder "null" in the item attribute (DynamoDBDataStoreImpl.MarshalItem). The harness expects a JSON tombstone with a key property, the item key or $deleted. This fails read-write/data source deletions respect versioning for each store (both harness versions) and, in v3, the five store recovery tests that check a deleted flag after the write back. With a one-line serializer change that writes "key": "$deleted", the Redis and Consul tests pass, and the recovery write back itself works; DynamoDB needs its own fix.
2. ConsulDataStoreImpl.GetAllAsync iterates result.Response, which is null when no key has the collection's prefix, so reading an empty collection throws. This fails collection cardinality/collection holds no flags for Consul.

These need SDK and store changes, which this PR does not make. For the keyless tombstone, the v3 harness's own tombstone suite lists {"version":N,"deleted":true} as a shape that .NET, Java, and Node write and that readers must accept, so for Redis and Consul the fix may belong in the harness's read-write matcher instead. DynamoDB's "null" placeholder is not one of the accepted shapes. Until one of these lands, CI does not check the store write back after recovery or the store side of deletions for any store; the only recovery test that runs checks evaluations from memory during the outage.

Testing

With Redis, DynamoDB local, and Consul running in Docker on their default ports:

• Harness v2 (2.41.1), full suite with persistence enabled and the suppression file: all tests passed (4989 ran).
• Harness v3 (3.2.0-alpha.15, from v3 at 58f4122), full suite with persistence enabled and the FDv2 suppression file: all tests passed (5174 ran).

Without the suppressions, the persistence suites fail exactly the tests listed above (4 in v2, 19 in v3).

After the review changes (the store projects, the port default, the readiness wait), both persistence suites pass again with the suppressions (v3: 141 ran; v2: 111 ran), and LaunchDarkly.ServerSdk.sln builds with no errors.

This is the dotnet-server-sdk-v9 version of #391.

_{Opened from termag}

---

Note

Overview
Enables the SDK test harness’s persistent-store suites in CI by wiring the contract test service to real Redis, DynamoDB, and Consul integrations and extending the shared contract-test GitHub Action.

The contract test service now maps harness FDv1 persistentDataStore and FDv2 dataSystem.store into Components.PersistentDataStore (Redis, DynamoDB, Consul) with prefix/cache options, 500 ms fail-fast client settings for recovery tests, and daemon mode (ExternalUpdatesOnly) when a store is configured without streaming/polling. It advertises the new persistence capabilities. Wrapper projects under Stores/ compile each integration’s sources against the in-repo SDK so CI does not pull a second published SDK copy.

CI: enable_persistence_tests and test_service_port are plumbed through the composite action; when enabled it starts stores, waits on ports 6379/8000/8500 and Consul leadership, and launches the service on a non-8000 port (DynamoDB local uses 8000). Server SDK workflow turns persistence on Linux only and uses port 9000.

Known integration gaps are temporarily skipped via suppression entries (deletion tombstone shape without "key", DynamoDB "null" deletes, Consul empty collection reads)—CI still runs the rest of the persistence suites.

^{Reviewed by Cursor Bugbot for commit 8f77f3f. 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 8f77f3f. Configure here.}