Code reading: Why panic when got singlerecord?

zgcbj · February 23, 2024, 6:48am

tikv/tikv/blob/master/src/storage/txn/actions/check_txn_status.rs#L307


    key: Key,
    lock: &Lock,
    is_pessimistic_txn: bool,
    collapse_rollback: bool,
) -> Result<Option<ReleasedLock>> {
    let overlapped_write = match reader.get_txn_commit_record(&key)? {
        TxnCommitRecord::None { overlapped_write } => overlapped_write,
        TxnCommitRecord::SingleRecord { write, commit_ts }
            if write.write_type != WriteType::Rollback =>
        {
            panic!(
                "txn record found but not expected: {:?} {} {:?} {:?} [region_id={}]",
                write,
                commit_ts,
                txn,
                lock,
                reader.reader.snapshot_ext().get_region_id().unwrap_or(0)
            )
        }
        _ => return Ok(txn.unlock_key(key, is_pessimistic_txn, TimeStamp::zero())),
    };

cfzjywxk · February 26, 2024, 8:23am

This situation implies that there are inconsistency states, meaning the lock that was expected to be rolled back is found in the storage layer associated with the commit record of the same transaction. It’s not straightforward to clean up or commit the lock, hence the panic.

zgcbj · February 27, 2024, 2:16am

Can you help draw out the inconsistent state that causes panic like the one in the picture?

zgcbj · March 14, 2024, 9:08am

After looking at the code, I understand that the bug was caused by me. The data in lock cf was not deleted, but the commit records were written in write cf. This caused a problem with the transaction.

Normally, the deletion of data in lock cf and the writing of commit records in write cf should happen together in the same write batch, and be submitted to rocksdb. It should not occur that lock cf was not deleted while write cf was committed. Therefore, it should panic. It was this panic that helped discover this bug, so kudos to the developers of tidb!