100w test

[hongyunyan]

What problem does this PR solve?

Issue Number: close #xxx

What is changed and how it works?

Check List

Tests

• Unit test
• Integration test
• Manual test (add detailed scripts or steps below)
• No code

Questions

Will it cause performance regression or break compatibility?

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

Release note

Please refer to [Release Notes Language Style Guide](https://pingcap.github.io/tidb-dev-guide/contribute-to-tidb/release-notes-style-guide.html) to write a quality release note.

If you don't think this PR needs a release note then fill it with `None`.

[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: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 84c8fca6-e45a-4c1b-9175-ba3a39841a4e

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

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

[ti-chi-bot]

This cherry pick PR is for a release branch and has not yet been approved by triage owners.
Adding the do-not-merge/cherry-pick-not-approved label.

To merge this cherry pick:

1. It must be LGTMed and approved by the reviewers firstly.
2. For pull requests to TiDB-x branches, it must have no failed tests.
3. AFTER it has lgtm and approved labels, please wait for the cherry-pick merging approval from triage owners.

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.

[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 lidezhu 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

[gemini-code-assist]

Code Review

This pull request updates the project to Go 1.25 and introduces features such as dynamic log redaction, failpoint management via API, and table ID-based paths for cloud storage. It also includes architectural improvements to the coordinator's bootstrap and GC cleanup logic, along with fixes for DDL ordering and virtual column handling in sinks. Technical feedback identifies potential API hangs in the coordinator due to missing context checks in wait loops, a resource leak in the cloud storage writer when write operations fail, and a potential busy-wait performance issue in the block event executor.

I am having trouble creating individual review comments. Click here to see my feedback.

coordinator/controller.go (656-664)

This loop waits for the operator to finish without any timeout or context cancellation check. If the operator gets stuck, the API request will hang indefinitely. It is recommended to use a select statement to check for ctx.Done().

	ticker := time.NewTicker(time.Second)
	defer ticker.Stop()
	for {
		if op.IsFinished() {
			break
		}

		select {
		case <-ctx.Done():
			return 0, context.Cause(ctx)
		case <-ticker.C:
			count += 1
			log.Info("wait for stop changefeed operator finished", zap.Int("count", count), zap.Any("id", id))
		}
	}

coordinator/controller.go (692-700)

This loop waits for the operator to finish without any timeout or context cancellation check. If the operator gets stuck, the API request will hang indefinitely. It is recommended to use a select statement to check for ctx.Done().

	ticker := time.NewTicker(time.Second)
	defer ticker.Stop()
	for {
		if op.IsFinished() {
			break
		}

		select {
		case <-ctx.Done():
			return context.Cause(ctx)
		case <-ticker.C:
			count += 1
			log.Info("wait for stop changefeed operator finished", zap.Int("count", count), zap.Any("id", id))
		}
	}

downstreamadapter/sink/cloudstorage/writer.go (254-256)

If writer.Write returns an error, the function returns immediately without calling writer.Close. This can lead to resource leaks (e.g., open file descriptors or incomplete multipart uploads in cloud storage). You should ensure writer.Close is called even if Write fails.

		if _, inErr = writer.Write(ctx, buf.Bytes()); inErr != nil {
			_ = writer.Close(ctx)
			return 0, 0, inErr
		}

downstreamadapter/dispatcher/block_event_executor.go (61-71)

This logic can lead to a busy-wait loop if the ready queue only contains dispatchers that are currently inUse. This will cause high CPU usage as workers repeatedly pop and re-push the same dispatcher IDs. Consider using a more efficient way to handle per-dispatcher task serialization, such as a set of per-worker queues or a more advanced scheduling mechanism.