coordinator: handle errors from regressed checkpoint status (#5779)

[ti-chi-bot]

This is an automated cherry-pick of #5779

What problem does this PR solve?

Issue Number: close #5709

What is changed and how it works?

Before this change, Changefeed.UpdateStatus ignored maintainer status reports whose CheckpointTs was lower than the checkpoint already stored in the coordinator. This kept checkpoint updates monotonic, but it also dropped MaintainerStatus.Err carried by those reports. As a result, retryable maintainer errors could be missed and the changefeed would not enter warning/backoff as expected.

This change keeps the monotonic checkpoint rule while still processing reported errors. If a maintainer reports a lower checkpoint without errors, the status is ignored as before. If it reports a lower checkpoint with errors, TiCDC copies the status, replaces the copied CheckpointTs with the coordinator's current checkpoint, and sends the copied status through the existing fast-fail and backoff checks.

With this behavior, maintainer errors can update the changefeed state and trigger retry/backoff, while the stored checkpoint never decreases and the original maintainer status object is not mutated.

Check List

Tests

• Unit test
• Integration test

Questions

Will it cause performance regression or break compatibility?

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

Release note

 Fix an issue where TiCDC could ignore maintainer errors when the reported checkpoint regressed.

Summary by CodeRabbit

• Bug Fixes
  • Improved changefeed status handling when no new status is provided.
  • Ensured retryable errors are processed correctly even when status checkpoints move backward.
  • Preserved accurate warning state, error details, and retry behavior during checkpoint regressions.

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

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

Run ID: ba1e82ba-f130-41a4-9b96-2fff30529521

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

[ti-chi-bot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: wk989898

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Details

Needs approval from an approver in each of these files:

• OWNERS [wk989898]

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