源码阅读疑问：tikv rollback_lock 这里，获取到了 SingleRecord 为什么要panic？

[TiDBer_jYQINSnf]

这块代码的307行，为什么要panic？
能从原理上给解释下为什么吗？

[kkpeter (Upstream889)]

函数是做rollback, if 判断写了 write.write_type 不是 WriteType::Rollback, 不符合预期。只看这块代码，其他的我也不知道

[ylldty (Ti D Ber Q Yky5 Dvm)]

是这样的，回滚的过程中发现事务已经提交了，那肯定哪里有 bug 了。singleRecord 的记录可能是提交记录，也可能是回滚记录

[TiDBer_jYQINSnf]

[2024/03/05 16:25:37.411 +08:00] [FATAL] [lib.rs:465] [“txn record found but not expected: txn @447507672037326851”] [backtrace=" 0: tikv_util::set_panic_hook::{{closure}}
at tikv/components/tikv_util/src/lib.rs:464:18
1: std::panicking::rust_panic_with_hook
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/panicking.rs:626:17
2: std::panicking::begin_panic_handler::{{closure}}
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/panicking.rs:519:13
3: std::sys_common::backtrace::__rust_end_short_backtrace
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/sys_common/backtrace.rs:141:18
4: rust_begin_unwind
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/panicking.rs:515:5
5: std::panicking::begin_panic_fmt
at /rustc/2faabf579323f5252329264cc53ba9ff803429a3/library/std/src/panicking.rs:457:5
6: tikv::storage::txn::actions::check_txn_status::rollback_lock
at tikv/src/storage/txn/actions/check_txn_status.rs:154:13
7: tikv::storage::txn::actions::check_txn_status::check_txn_status_lock_exists
at tikv/src/storage/txn/actions/check_txn_status.rs:50:17
8: <tikv::storage::txn::commands::check_txn_status::CheckTxnStatus as tikv::storage::txn::commands::WriteCommand<S,L>>::process_write
at tikv/src/storage/txn/commands/check_txn_status.rs:93:54
9: tikv::storage::txn::commands::Command::process_write
at tikv/src/storage/txn/commands/mod.rs:615:43
10: tikv::storage::txn::scheduler::Scheduler<E,L>::process_write::{{closure}}

是这个调用栈，check_txn_status 发现的。
为什么会认为要回滚。如果发现了已经提交了，为什么要panic？直接认为不需要回滚不行吗？

[ylldty (Ti D Ber Q Yky5 Dvm)]

check txn status 的时候，如果发现 primary 锁已经超时，会进行立刻回滚的。
关于回滚时候发现了提交记录，为何一定要 panic，那就是 tikv 的同学认为这种是非常严重的问题了，肯定是哪里有 bug，需要提前定位，立刻解决

[TiDBer_jYQINSnf]

好的，我再看看，谢谢。

[TiDBer_jYQINSnf]

@ylldty

关于回滚时候发现了提交记录，为何一定要 panic，

看了看代码，明白了，是我搞的bug
lock cf中的数据没删掉，write cf中提交记录写上了。这样这个事务就有问题。

正常情况下，lock cf中数据的删除和write cf提交记录的写入是同一个writebatch，一起提交到rocksdb的，不会出现lock cf没删掉，write cf提交了的情况，所以应该panic。也正是因为这个panic，发现了这个bug，给tidb的开发人员点赞！

进一步补充下：
lock_cf 中代表的是锁，check_txn_status 扫描的时候，发现一个残留的锁，并且ttl超时了，尝试rollback，然后扫描write cf的时候，又发现了一条提交记录，代表这个事务已经提交了。这就异常了。
下图中的<1,(D,pk,1,100…)>这条记录代表着删除锁，put<1_110,100>代表着事务已经在110 ts的时候提交了。

我的不一致情况为 <1,(D,pk,1,100…）> 消失了，get的时候就又看到了<1,(w,pk,1,100）>
贴个图