bedrock-kv / bedrock / eecf16dcfafe2a292a260de84aa84802b538deaf

73%

Build Type

push

github

Committed by web-flow

Commit Message

Record read conflicts when a read is issued; cover key-selector scan spans (bedrock-udr, bedrock-v2c) (#109)

## Why

Two transactions could both read a missing key, both write it, and both
commit:

```
Transaction A                     Transaction B
get("job/123/owner") → not found
                                  get("job/123/owner") → not found
set("job/123/owner", "worker-A")
                                  set("job/123/owner", "worker-B")
commit ✓                          commit ✓   ← should have aborted
```

The resolver can only abort B if A's read conflict set contains the key
— but a storage miss (`{:error, :not_found}`) took an error path that
skipped conflict recording entirely. **Reading nothing is still
reading:** "the key was absent" is information the transaction acted on.
(Same defect as #108; found via Job Queue QA.)

Key-selector reads had the same hole, wider: a selector's result depends
on *every* key between its anchor and the key it resolves to — an insert
anywhere in that span changes the resolution — but only the resolved key
was recorded on a hit, and nothing on a miss.

## What

Both fixes follow FoundationDB (`fdbclient/NativeAPI.actor.cpp`):

- **Point reads** register the conflict **when the read is issued**,
before storage answers (`record_read_intent/3`). No result shape —
value, miss, or error — can dodge it, because recording never looks at
the result. Mirrors `Transaction::get()`'s
`push_back(singleKeyRange(key))` before the read.
- **Selector reads** register **after resolution** (the span isn't
knowable earlier — FDB's `extraConflictRanges`): a hit records
`[min(anchor, resolved), key_after(max(anchor, resolved)))`; a miss
records the shard range that was scanned and found empty (FDB's
empty-range-read analog).

Deliberate, FDB-matching behaviors: `snapshot: true` reads record
nothing; reads satisfied from your own writes record nothing; a point
read that *fails* after issue still leaves its conflict behind.

## ... (continued)

Coverage Stats

25 of 26 new or added lines in 1 file covered. (96.15%)

1 existing line in 1 file now uncovered.

5734 of 7856 relevant lines covered (72.99%)

1003.27 hits per line