fix: Report an incomplete DynamoDB auto-config cache write

[keelerm84]

Summary

dynamoDBStore.SetAll returned nil even when it had written nothing. A failed batch, an unprocessed item, or an environment over the size limit was logged and skipped, and the function reported success anyway.

The damage is not at write time. A later startup reads that partial snapshot and serves it as the whole configuration, marking Relay fully configured with a subset of its environments. SDKs for the missing ones then get a 401 rather than a 503 — and a LaunchDarkly SDK treats a 401 on its data source as terminal, so it stops retrying for good rather than backing off and recovering.

The fix counts everything that could not be written — build failures, size-limit drops, failed batches, unprocessed items — and returns an error naming the loss. The write still continues past a failed batch, because a partial cache is worth more than none, but the caller is told instead of reassured. persistPut already logs SetAll's error, so the problem surfaces when it happens rather than on some later startup.

Redis is unaffected: its SetAll is atomic via MULTI/EXEC.

Not fixed here

Reading a partial snapshot is still indistinguishable from reading a complete one, so a snapshot written before this change is still served as authoritative. Detecting that needs a completeness marker in the cache, which is a schema change and its own piece of work.

Origin

Found by a review of #866 and split out of it. It has nothing to do with retry behavior beyond having been noticed at the same time.

---

Note

Overview
dynamoDBStore.SetAll now fails when the DynamoDB snapshot is incomplete instead of always returning success after partial writes.

The store tracks every item that cannot be written—marshal/build errors, oversize drops, whole failed BatchWriteItem chunks, and unprocessed items—and returns an error like "N of M items could not be written". Batch writes still continue after a failed chunk so a partial cache can land, but callers are no longer told the write fully succeeded. batchWrite is changed to return a drop count to support this accounting without double-counting items in the error total.

New dynamodb_store_test.go exercises this with an httptest fake DynamoDB: success path, unprocessed items, failed batches, oversized envs (partial write still happens), and 25-item chunking.

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

[cursor]

Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.

^{❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.}

^{Reviewed by Cursor Bugbot for commit 6b2f796. Configure here.}