client: use batch-level runtime trace regions (#10965)

[ti-chi-bot]

This is an automated cherry-pick of #10965

What problem does this PR solve?

Issue Number: Close #10964

Batched PD client requests currently start one Go runtime trace region per request on the same dispatcher goroutine. Runtime trace regions are goroutine-local and must be nested in LIFO order, so representing batched requests as overlapping per-request regions can make go tool trace fail with errors like:

misuse of region in goroutine 400: region end {898020 pdclient.tsoReqSend} when the inner-most active region start event is {898021 pdclient.tsoReqSend}

This can make Go trace timeline and derived pprof outputs unusable during production diagnosis.

What is changed and how does it work?

Use one batch-level runtime trace region for each batched send path, while preserving per-request opentracing spans:

• Replace per-request pdclient.tsoReqSend runtime regions with one pdclient.tsoReqSendBatch region in the TSO dispatcher.
• Replace per-request pdclient.regionReqSend runtime regions with one pdclient.regionReqSendBatch region in the region router client.
• Keep the per-request opentracing spans unchanged, so request-level tracing remains available through opentracing.

client: use batch-level runtime trace regions

Runtime trace regions are goroutine-local execution intervals and must be
nested in LIFO order. The PD client batch send paths started one runtime trace
region per request on the same dispatcher goroutine, which can make batched
requests appear as overlapping/nonnested regions and break Go trace parsing.

Use a single batch-level runtime trace region for each batched send path and
keep per-request detail in opentracing spans.

Check List

Tests

• Unit test

Code changes

• None

Side effects

• None

Related changes

• PR to update pingcap/docs/pingcap/docs-cn: None
• PR to update pingcap/tiup: None
• Need to cherry-pick to the release branch: No

Release note

None.

Summary by CodeRabbit

• Bug Fixes
  • Improved tracing consistency for batched request processing across router and TSO dispatch flows.
  • Reduced tracing overhead by using a single batch-level trace for grouped requests rather than creating multiple per-request traces.

[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 husharp 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:

• OWNERS

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

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: 6caee245-f5b4-405d-b201-d60c76782c7f

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

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.}