dbconn(dm): redact arguments when retrying connection resets

[Tema]

What problem does this PR solve?

Issue Number: ref #11489

When DM retries a failed connection reset, the retrying reset connection log includes query arguments even when redact-info-log is enabled.

What is changed and how it works?

Use the existing ZapRedactString helper for the arguments field. With redaction enabled, the field contains ?; with redaction disabled, it keeps its existing output.

Add a regression test covering both settings, emitted log fields, and retry decisions.

Check List

Tests

• Unit test: go test -race -tags=intest ./dm/syncer/dbconn
• Formatting: make fmt FILES='dm/syncer/dbconn/db.go dm/syncer/dbconn/db_test.go'

Questions

Will it cause performance regression or break compatibility?

No material performance impact or compatibility change. Retry behavior is unchanged, and argument redaction follows the existing configuration option.

Do you need to update user documentation, design documentation or monitoring documentation?

No. This fixes the existing redact-info-log option without adding configuration.

Release note

Fix query arguments appearing in DM logs when retrying connection resets with `redact-info-log` enabled.

Summary by CodeRabbit

• Bug Fixes
  • Sensitive argument values are now redacted in connection-retry logs when redaction is enabled. Retry behavior remains unchanged.

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is NOT APPROVED

This pull-request has been approved by:
Once this PR has been reviewed and has the lgtm label, please assign bb7133 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:

• dm/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]

Hi @Tema. Thanks for your PR.

I'm waiting for a pingcap member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work.

Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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.

[pingcap-cla-assistant]

All committers have signed the CLA.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

• Configuration used: Organization UI
• Review profile: CHILL
• Plan: Advanced
• Run ID: 4237a00b-d49f-48e2-bddd-749c5181aac1

📥 Commits

Reviewing files that changed from the base of the PR and between 4e37e15 and ad82692.

📒 Files selected for processing (2)

• dm/syncer/dbconn/db.go
• dm/syncer/dbconn/db_test.go

Included review availability: This review used your included allowance. Your plan provides up to 2 included reviews per hour; 1 remain after this review.

📝 Walkthrough

The reset-connection retry log now records arguments through the redacting logger field. A test checks the logged value with redaction enabled and disabled.

Changes: Reset retry log redaction

Layer / File(s)	Summary
Redacting retry log and test dm/syncer/dbconn/db.go, dm/syncer/dbconn/db_test.go	The retry log records arguments through the redacting logger field. The test checks retryability, logged fields, argument redaction with both settings, and non-retryable error handling.

Priority: ➖ Normal

Estimated code review effort: 2 (Simple) | ~10 minutes

Change: Bug fix

Merge Risk: ⚪ Minimal · up to ad826

The reset-retry log redacts arguments when enabled and retains the existing value when disabled. No remaining actionable merge risk is identified.

Pre-merge checks · 4 · 1

Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage		Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. Docstring coverage is scoped to functions touched by this diff. Analyzed 2 functions across 2 files.	Write docstrings for the functions missing them to satisfy the coverage threshold.

Passed checks (4 passed)

Check name	Status	Explanation
Title check		The title clearly and concisely describes the main change: redacting arguments during connection-reset retries in DM.
Description check		The description includes the issue reference, problem statement, implementation details, unit test and formatting checks, compatibility and documentation answers, and a release note.
Linked Issues check		Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check		Check skipped because no linked issues were found for this pull request.

• Fix all pre-merge checks with AI

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create a new PR

• Autofix · Keep fixing CodeRabbit findings and required CI, and resolving merge conflicts

Warning

Some tools did not complete. Review the errors below.

🔧 golangci-lint (2.13.2)

golangci-lint (2.13.2) skipped for .golangci.yml: configuration requires version: "2". Migrate older configurations using golangci-lint migrate and review the result; see https://golangci-lint.run/docs/product/migration-guide/.

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

_{I’m a rabbit; I nibble and read,
The retry log now hides what it need.
With redaction switched on,
The raw value is gone,
And tests check each logging detail.}

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

[ti-chi-bot]

Now you can start all CI jobs with /test all in comment or query the triggers with /test ?