Description
TwoPhaseCommitter::pessimisticLockBatch() handles only three KeyError variants per KvPessimisticLock response: deadlock (throw), locked ($needRetry = true) and conflict (throw). Any other variant (e.g. abort, retryable, txn_not_found) falls through the error loop with $needRetry left false, so the batch is treated as fully locked and prewrite proceeds as if every lock was acquired.
This mirrors TXN-09 (#214) but in the lock-acquisition path: the transaction can commit keys whose pessimistic lock was never acquired — the same silent-continue family as TXN-14 (#219). Found while implementing #219 (the post-loop LockWaitTimeoutException throw now covers both budget-exhaustion exits, but unrecognised error variants still exit the loop silently).
Where
src/Client/TxnKv/TwoPhaseCommitter.php — pessimisticLockBatch(), error branch (if ($needRetry) { ... } else { ... }, ~lines 579-608 on master)
Suggested fix
Terminate the error loop with an unconditional typed exception (e.g. TiKvException / TransactionConflictException) in a default branch for unrecognised variants (mirroring the #214 approach), and add a regression test asserting that an unhandled KvPessimisticLock KeyError blocks prewrite (no KvPrewrite/KvCommit issued).
Description
TwoPhaseCommitter::pessimisticLockBatch()handles only threeKeyErrorvariants perKvPessimisticLockresponse:deadlock(throw),locked($needRetry = true) andconflict(throw). Any other variant (e.g.abort,retryable,txn_not_found) falls through the error loop with $needRetry leftfalse, so the batch is treated as fully locked and prewrite proceeds as if every lock was acquired.This mirrors TXN-09 (#214) but in the lock-acquisition path: the transaction can commit keys whose pessimistic lock was never acquired — the same silent-continue family as TXN-14 (#219). Found while implementing #219 (the post-loop
LockWaitTimeoutExceptionthrow now covers both budget-exhaustion exits, but unrecognised error variants still exit the loop silently).Where
src/Client/TxnKv/TwoPhaseCommitter.php—pessimisticLockBatch(), error branch (if ($needRetry) { ... } else { ... }, ~lines 579-608 on master)Suggested fix
Terminate the error loop with an unconditional typed exception (e.g.
TiKvException/TransactionConflictException) in a default branch for unrecognised variants (mirroring the #214 approach), and add a regression test asserting that an unhandledKvPessimisticLockKeyErrorblocks prewrite (noKvPrewrite/KvCommitissued).