The kvproto refresh (tikv/client-rust#550) brought shared-lock semantics into the wire surface: a SharedLock wrapper whose real holders live in shared_lock_infos ("DO NOT read from the wrapper LockInfo"), with SharedPessimisticLock members. That PR lands a REFUSAL posture — resolution errors explicitly rather than resolving transaction 0 or silently dropping members via wrapper-field filters — plus wrapper-aware API-v2 keyspace codecs (type-keyed; the empty logical key stays valid).
Full support is this issue:
- Flatten wrappers into members at the resolution entries (replacing the refusal)
- Teach the resolver's pessimistic special cases
SharedPessimisticLock (the resolving_pessimistic_lock decisions and the live-lock TxnNotFound branch match only Op::PessimisticLock today)
- Cleanup-filter awareness (
async_commit_only must filter member locks, not wrapper fields)
- Tests for all of the above; a differential scenario once a TiKV version that emits shared locks is pinnable
Related: rules PL-6 (InShareMode), roadmap §5.2/§7 fair-locking family. The review trail that mapped these hazards lives in tikv/client-rust#550's history.
The kvproto refresh (tikv/client-rust#550) brought shared-lock semantics into the wire surface: a
SharedLockwrapper whose real holders live inshared_lock_infos("DO NOT read from the wrapper LockInfo"), withSharedPessimisticLockmembers. That PR lands a REFUSAL posture — resolution errors explicitly rather than resolving transaction 0 or silently dropping members via wrapper-field filters — plus wrapper-aware API-v2 keyspace codecs (type-keyed; the empty logical key stays valid).Full support is this issue:
SharedPessimisticLock(theresolving_pessimistic_lockdecisions and the live-lock TxnNotFound branch match onlyOp::PessimisticLocktoday)async_commit_onlymust filter member locks, not wrapper fields)Related: rules PL-6 (
InShareMode), roadmap §5.2/§7 fair-locking family. The review trail that mapped these hazards lives in tikv/client-rust#550's history.