grenadeandClaude Opus 5
d461d466c2
A snapshot_download fans out across a repo's files, so several transfers finish at once and each rewrites the same manifest document. The read-merge-write had no conditional put behind it: two writers that read the same document both wrote their own version, and the second silently dropped the first's entry. The verify-after-write retry caught most of that, but the write happens in the detached transfer task -- after the client already has its bytes -- so a lost entry surfaced only later, as a sealed instance claiming never to have seen a file it had served. That breaks the fetch-once retention guarantee. Adds a compare-and-set pair to the Store port (get_versioned / put_if_version, conditional on the etag last read) and uses it for manifest updates, so a racing write is refused and retried rather than merged away. The local filesystem store cannot do conditional updates, so it reports supports_compare_and_set() = false and the caller keeps the verify-after-write path for it. Also serialises manifest writes per key within the process. CAS alone is correct but turns eight parallel workers into eight writers contending for one document, burning the retry budget on self-inflicted collisions; the lock makes the common case uncontended and leaves the retry loop for genuinely concurrent writers -- another instance, or the CLI against the same bucket. Regression test fetches twelve files of one repo concurrently and asserts every one survives into the manifest and replays when sealed. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01XZG2i4AmfSqE97EJGBVb64