Conversation
Signed-off-by: ekexium <[email protected]>
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: The full list of commands accepted by this bot can be found here. DetailsNeeds approval from an approver in each of these files:Approvers can indicate their approval by writing |
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
🚧 Files skipped from review as they are similar to previous changes (1)
📝 WalkthroughWalkthroughAdds and adjusts logging across two-phase commit cleanup, batch cleanup RPCs, pessimistic rollback, and lock resolution; introduces a local helper mapping transaction status to action labels. Changes are logging-only and do not alter exported signatures or control-flow outcomes. Changes
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
🚥 Pre-merge checks | ✅ 2 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (2 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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 |
There was a problem hiding this comment.
🧹 Nitpick comments (1)
txnkv/txnlock/lock_resolver.go (1)
1266-1276: Consider log level for high-frequency paths.This Info-level log is emitted when a lock is already resolved by
CheckTxnStatus, which could be frequent in workloads with high lock contention. Consider whether Debug level might be more appropriate for the "skipped rpc" cases to reduce log volume in production, while keeping Info level for actual RPC completions.That said, if enhanced observability is the explicit goal of this PR, Info level is acceptable.
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed. In `@txnkv/txnlock/lock_resolver.go` around lines 1266 - 1276, The Info-level log inside the resolved-by-check block should be lowered to Debug to avoid high-volume logging on frequent "skipped rpc" paths: update the logutil.Logger(bo.GetCtx()).Info call in the block guarded by resolveLite && bytes.Equal(l.Key, l.Primary) (where resolveAction is from resolveActionLabel and status provides CommitTS) to use Debug (preserving the same message and zap fields: action, txnStartTS, commitTS, resolveLite, resolvedByCheckTxnStatus) so observability is kept but noisy Info logs are avoided in production.
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Nitpick comments:
In `@txnkv/txnlock/lock_resolver.go`:
- Around line 1266-1276: The Info-level log inside the resolved-by-check block
should be lowered to Debug to avoid high-volume logging on frequent "skipped
rpc" paths: update the logutil.Logger(bo.GetCtx()).Info call in the block
guarded by resolveLite && bytes.Equal(l.Key, l.Primary) (where resolveAction is
from resolveActionLabel and status provides CommitTS) to use Debug (preserving
the same message and zap fields: action, txnStartTS, commitTS, resolveLite,
resolvedByCheckTxnStatus) so observability is kept but noisy Info logs are
avoided in production.
ℹ️ Review info
Configuration used: defaults
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (4)
txnkv/transaction/2pc.gotxnkv/transaction/cleanup.gotxnkv/transaction/pessimistic.gotxnkv/txnlock/lock_resolver.go
There was a problem hiding this comment.
Pull request overview
Adds more informational logging around txn lock resolution and 2PC secondary cleanup to make “resolve lock” paths easier to trace.
Changes:
- Log “rpc finished” and “skipped rpc” events for resolve-lock / resolve-region / resolve-pessimistic-lock paths.
- Introduce a small helper to label resolve action as commit vs rollback.
- Promote 2PC cleanup completion log level from Debug to Info and add per-batch rollback logs.
Reviewed changes
Copilot reviewed 4 out of 4 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| txnkv/txnlock/lock_resolver.go | Adds structured Info logs for resolve RPC completion/skip and a helper for action labeling. |
| txnkv/transaction/pessimistic.go | Adds Info log after secondary pessimistic rollback batch handling. |
| txnkv/transaction/cleanup.go | Adds Info log for secondary cleanup batch rollback completion. |
| txnkv/transaction/2pc.go | Changes cleanup “done” log to Info with new wording. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
txnkv/transaction/2pc.go
Outdated
| zap.Bool("isPessimistic", c.isPessimistic), zap.Bool("isOnePC", c.isOnePC())) | ||
| } else { | ||
| logutil.Logger(ctx).Debug("2PC clean up done", | ||
| logutil.Logger(ctx).Info("2PC secondary lock cleanup finished", |
There was a problem hiding this comment.
This changes a previously-Debug completion log to Info. If 2PC cleanup runs frequently, this can significantly increase log volume in production. Consider keeping this at Debug, adding sampling/rate limiting, or gating with a verbosity/config flag so Info-level remains high-signal.
| logutil.Logger(ctx).Info("2PC secondary lock cleanup finished", | |
| logutil.Logger(ctx).Debug("2PC secondary lock cleanup finished", |
There was a problem hiding this comment.
It means the query fails because of some internal errors which should not happen most of the times, and the error would be returned to the client.
We could check if there is exact prewrite lock rollback or cleanup, only print it in this path. The pessimistic lock rollback does not matter.
Another option is to print related information in the rollback or resolve action where keys are also printable.
Signed-off-by: ekexium <[email protected]>
txnkv/transaction/2pc.go
Outdated
| zap.Bool("isOnePC", c.isOnePC())) | ||
| zap.Uint64("txnStartTS", c.startTS), zap.Bool("isOnePC", c.isOnePC())) | ||
| } else { | ||
| logutil.Logger(ctx).Debug("2PC pessimistic lock rollback finished", |
There was a problem hiding this comment.
Should the prewrite lock rollback which happens in situations like when pessimistic prewrite fails also be printed?
Signed-off-by: ekexium <[email protected]>
Add more logs in the resolve lock paths.
The only concern is when conflicts are frequent, the logs can flood.
Summary by CodeRabbit