Future version chunks tracked but data never written

When a future version chunk arrives (version > active version), the code inserts the chunk_key into received_chunks_ but returns immediately without writing the actual data to the backing store. Later, when that version becomes active and retries arrive for those chunks, they're found in received_chunks_ and treated as duplicates, returning early without writing data. The comment says "buffer for later processing" but only the chunk key is tracked—the actual data is discarded. This causes data loss for any chunks that arrive before their version becomes active.

We can simply remove received_chunks.insert(chunk_key) and let the client retry.

TOCTOU race allows stale retries to corrupt state

A time-of-check-time-of-use race exists between the two lock acquisitions. The code reads highest_completed and performs the stale version check in the first critical section (lines 159-167), then releases the lock and computes is_active_version outside the lock (lines 169-171). When the second lock is acquired (line 177), the stale is_active_version is used without re-validation. If another thread completes the version between the two lock acquisitions, a stale retry can bypass the staleness check, find an empty received_chunks_ (cleaned up by the completing thread), and trigger a new WriteAcquire for an already-completed version. This can leave the object in an inconsistent state since only one chunk would be written.

can you return this out with the status with StatusOr instead of an out param

We have RAY_testing_rpc_failure which can inject failures for you and then can test functionality from python with the injected failures.

why adding timeout as a param here if it's effectively hardcoded to -1 anyways