txnkv: Support resolve txn file locks

[pingyu]

Summary

Pick resolve locks part from #1119.

Resolve locks logics only, to be used for components (e.g. TiCDC) which will try to resolve locks.

Should have no impact when the txn file feature is disabled and TiDB do not generate txn file transactions.

The full txn file transaction feature will be in another PR (see #1998).

• support resolving transaction file locks in txn lock resolver paths
• keep batch client collapse handling compatible with txn file resolve lock requests
• add/update coverage for the related client behavior

Tests

• go test ./internal/client ./txnkv/txnlock

Summary by CodeRabbit

• Bug Fixes
  • Enhanced transaction lock resolution to properly handle transaction file information during lock resolution and cleanup operations.

[coderabbitai]

📝 Walkthrough

Walkthrough

IsTxnFile is added as a field to the Lock struct, sourced from kvrpcpb.LockInfo, and propagated through the lock resolution pipeline: BatchResolveLocks tracks txn-file IDs, getTxnStatus sets the flag on CheckTxnStatusRequest, resolveRegionLocks and resolveLock set it on ResolveLockRequest, and a comment notes the field is intentionally excluded from the singleflight collapse key.

Changes

IsTxnFile Propagation Through Lock Resolution

Layer / File(s)	Summary
Lock model with IsTxnFile field txnkv/txnlock/lock_resolver.go	Lock struct adds IsTxnFile bool, initialized from kvrpcpb.LockInfo in NewLock and included in Lock.String() output.
Batch resolution and status check propagation txnkv/txnlock/lock_resolver.go	BatchResolveLocks introduces a txnFileIDs map to record which txn IDs are txn-files across async-secondary and txnInfos paths, then sets IsTxnFile on each kvrpcpb.TxnInfo. getTxnStatus derives and sets IsTxnFile on CheckTxnStatusRequest.
Per-region and per-lock request propagation txnkv/txnlock/lock_resolver.go, internal/client/client_collapse.go	resolveRegionLocks and resolveLock populate ResolveLockRequest.IsTxnFile from Lock.IsTxnFile. A comment in resolveLockCollapseKey documents that IsTxnFile is implied by StartVersion and is not part of the collapse key.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

Possibly related PRs

• tikv/client-go#1981: Both PRs modify BatchResolveLocks and resolveRegionLocks request construction in txnkv/txnlock/lock_resolver.go, with overlapping changes to how ResolveLockRequest fields are populated.

Suggested labels

lgtm, approved

Suggested reviewers

• cfzjywxk
• ekexium

Poem

🐇 A flag called IsTxnFile hops through the code,
From LockInfo it blooms, then travels each road.
Through BatchResolve, getTxnStatus, requests galore,
Each resolve now carries the flag to the store.
The collapse key skips it — StartVersion's enough!
Little rabbit says: clean propagation is tough. 🎉

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 33.33% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title directly and clearly summarizes the main change: adding support for resolving transaction file locks in the txnkv lock resolver, which aligns with the primary objective of the pull request.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

txnkv/txnlock/lock_resolver.go (1)

900-907: ⚠️ Potential issue | 🟠 Major | 🏗️ Heavy lift

Key the resolved-status cache by IsTxnFile too.

getTxnStatus now builds different CheckTxnStatusRequest variants, but Line 1003 still short-circuits on a cache keyed only by txnID, and GetTxnStatus on Lines 900-907 can only populate that cache through the lockInfo == nil / IsTxnFile=false path. A prior lookup on the non-file path can therefore suppress the correctly flagged RPC for a txn-file lock (and vice versa), which risks resolving the transaction with a status produced under different server semantics.

Also applies to: 1001-1031

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@txnkv/txnlock/lock_resolver.go` around lines 900 - 907, The resolved-status
cache is currently keyed only by txnID, causing mismatches between file vs
non-file RPC variants; update the cache key and all cache lookups/writes in
getTxnStatus (and the path used by GetTxnStatus) to include the IsTxnFile flag
so entries distinguish CheckTxnStatusRequest variants; ensure any early-return
that uses lockInfo==nil/IsTxnFile=false and the code paths around the
CheckTxnStatusRequest construction (including the region around lines 1001-1031)
both read and populate the cache with the combined (txnID, IsTxnFile) key so a
prior lookup on one variant cannot suppress a correct RPC for the other.

🧹 Nitpick comments (1)

txnkv/txnlock/lock_resolver.go (1)

200-212: ⚡ Quick win

Add a doc comment for Lock.IsTxnFile.

Lock is part of the public txnkv surface, so the new exported field should explain what “txn file” means and when callers can expect it to be set.

As per coding guidelines, "Exported identifiers must have clear Go doc comments when they are part of the public client API".

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@txnkv/txnlock/lock_resolver.go` around lines 200 - 212, Add a Go doc comment
for the exported field Lock.IsTxnFile on the Lock struct that clearly explains
what a "txn file" is and when the flag is set; update the comment above the
Lock.IsTxnFile field (reference Lock.IsTxnFile) to describe its semantic meaning
(e.g., indicates the lock was created by a transaction using a transaction-file
based commit path or metadata persisted to a txn file), under what conditions
callers will see it true (e.g., specific commit/transaction modes or servers
that set this flag), and any implications for callers (e.g., how it changes lock
resolution behavior or expectations).

Source: Coding guidelines

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Outside diff comments:
In `@txnkv/txnlock/lock_resolver.go`:
- Around line 900-907: The resolved-status cache is currently keyed only by
txnID, causing mismatches between file vs non-file RPC variants; update the
cache key and all cache lookups/writes in getTxnStatus (and the path used by
GetTxnStatus) to include the IsTxnFile flag so entries distinguish
CheckTxnStatusRequest variants; ensure any early-return that uses
lockInfo==nil/IsTxnFile=false and the code paths around the
CheckTxnStatusRequest construction (including the region around lines 1001-1031)
both read and populate the cache with the combined (txnID, IsTxnFile) key so a
prior lookup on one variant cannot suppress a correct RPC for the other.

---

Nitpick comments:
In `@txnkv/txnlock/lock_resolver.go`:
- Around line 200-212: Add a Go doc comment for the exported field
Lock.IsTxnFile on the Lock struct that clearly explains what a "txn file" is and
when the flag is set; update the comment above the Lock.IsTxnFile field
(reference Lock.IsTxnFile) to describe its semantic meaning (e.g., indicates the
lock was created by a transaction using a transaction-file based commit path or
metadata persisted to a txn file), under what conditions callers will see it
true (e.g., specific commit/transaction modes or servers that set this flag),
and any implications for callers (e.g., how it changes lock resolution behavior
or expectations).

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro

Run ID: 40ab777f-fa4f-4d52-a6d3-4eced86d80d4

📥 Commits

Reviewing files that changed from the base of the PR and between 8df1c02 and 2a4426d.

📒 Files selected for processing (3)

• internal/client/client_collapse.go
• internal/client/client_test.go
• txnkv/txnlock/lock_resolver.go

[pingyu]

/retest

[pingyu]

/retest

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by: coocood
Once this PR has been reviewed and has the lgtm label, please assign cfzjywxk for approval. For more information see the Code Review Process.
Please ensure that each of them provides their approval before proceeding.

The full list of commands accepted by this bot can be found here.

Details

Needs approval from an approver in each of these files:

• internal/client/OWNERS
• txnkv/OWNERS

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[ti-chi-bot]

[LGTM Timeline notifier]

Timeline:

• 2026-06-15 02:22:07.732418458 +0000 UTC m=+1358628.802735848: ☑️ agreed by coocood.

[ti-chi-bot]

@pingyu: The following test failed, say /retest to rerun all failed tests or /retest-required to rerun all mandatory failed tests:

Test name	Commit	Details	Required	Rerun command
pull-integration-test-nextgen	37d99e2	link	false	/test pull-integration-test-nextgen

Full PR test history. Your PR dashboard.

Details

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here.