txnkv: preserve undetermined commit outcomes across retries and cancellation - #2063
Conversation
|
Important Review skippedReview was skipped as selected files did not have any reviewable changes. ⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Advanced Run ID: You can disable this status message by setting the Use the checkbox below for a quick retry:
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Advanced Run ID: 📒 Files selected for processing (11)
Included review availability: Your plan provides up to 2 included reviews per hour; 1 remains after this review. 📝 WalkthroughWalkthroughThe change preserves undetermined commit outcomes across request cancellation, prewrite retries, 2PC, 1PC, async commit, transaction-file commits, and pipelined commits. Tests cover unknown results, definitive failures, resolved RPC errors, fallback, cleanup, and rollback broadcasts. ChangesUndetermined commit result handling
Priority: ➖ Normal Estimated code review effort: 4 (Complex) | ~60 minutes Change: Bug fix · Severity of issue fixed: Medium Suggested reviewers: Merge Risk: ⚪ Minimal · up to No confirmed merge-blocking issue remains. The commit-result handling and its regression coverage are ready to merge. 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
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. Comment |
| // A lost async/1PC response can leave the result unknown. Ignore RPC errors caused | ||
| // by another failed batch's cancellation. A split can disable 1PC locally, whereas | ||
| // disabling async commit requires TiKV to confirm fallback. | ||
| if (handler.committer.isAsyncCommit() || handler.req.Prewrite().TryOnePc) && handler.sender.GetRPCError() != nil && atomic.LoadUint32(&handler.committer.prewriteCancelled) == 0 { |
There was a problem hiding this comment.
Is the following concurrent ordering expected?
- Starts two async-prewrite batches in separate regions.
- Obtains a definitive async-fallback response for one batch but delays delivering it.
- Lets the other batch's RPC error populate
undeterminedErr. - Delivers the already-obtained fallback response.
Because the failed prewrite prevents any commit request, the transaction appears definitively uncommitted, but the recorded error remains and becomes ErrResultUndetermined, also skipping cleanup. The existing test TestConfirmedFallbackWithRPCError covers the opposite ordering; should previously recorded async uncertainty be reconciled when fallback is later confirmed?
There was a problem hiding this comment.
Good catch. I reproduced this ordering on both the PR base and the current head, so this is a pre-existing issue.
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: ekexium, zyguan The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
|
/cherry-pick tidb-8.5 |
|
@gengliqi: The label(s) DetailsIn response to this:
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 ti-community-infra/tichi repository. |
|
@gengliqi: new pull request created to branch DetailsIn response to this:
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 ti-community-infra/tichi repository. |
Fix #2062
Description
Prevent ordinary errors from masking undetermined commit outcomes across retries, protocol fallback, and cancellation, including pipelined DML.
Preserve the undetermined state, return
ErrResultUndetermined, and skip failure cleanup while the outcome remains unknown. Definitive failures retain their existing behavior.Summary by CodeRabbit