Current behavior
KV deletion is logical: the latest tombstone removes a key from GET/LIST immediately, but historical content-addressed blobs remain retained and continue counting toward the space quota. Physical deletion is unsafe because blobs can be shared by multiple keys or historical versions.
Required design
- Reclaim a blob only after transactionally proving that no live or retained KV version references it.
- Define whether quota tracks retained physical bytes or only live logical values, and make accounting consistent with that definition.
- Keep deletion, conditional mutation, and GC safe under concurrent writers and multiple node replicas.
- Make GC resumable and idempotent after process or transaction failure.
- Expose enough metrics/logging to diagnose retained bytes and reclamation.
Acceptance criteria
- Deleting a unique value eventually reclaims its eligible blob bytes and quota.
- Deleting one of two keys that share identical content does not remove the surviving value.
- Replacing and deleting keys concurrently with GC cannot resurrect data or delete live data.
- Tests cover shared blobs, version history, tombstones, concurrent writers, interrupted GC, and quota behavior.
- Public KV/MCP documentation is updated when reclamation semantics ship.
Current behavior
KV deletion is logical: the latest tombstone removes a key from GET/LIST immediately, but historical content-addressed blobs remain retained and continue counting toward the space quota. Physical deletion is unsafe because blobs can be shared by multiple keys or historical versions.
Required design
Acceptance criteria