pingcap / pingcap/tidb

br: Misleading BR error message when restore is blocked by TiCDC CheckpointTS

Open
#70,719 2 comments 0 reactions 0 assignees View on GitHub
component/br contribution severity/minor type/bug
Dominant language
Go
Stars
40.5k
Forks
6.2k
PR merge metrics
PR metrics pending

Description

## Bug Report

### What did you do?

Run BR restore to a target cluster that has an existing TiCDC changefeed.

The changefeed was in a bad/stuck state and its CheckpointTS was not advancing.

### What did you expect to see?

For BR v8.2.0 and later, the error message should clearly explain the actual condition that blocks the restore:

* A TiCDC changefeed exists on the target cluster.
* The changefeed CheckpointTS is earlier than the BackupTS.

Ideally, the message should include the relevant CheckpointTS and BackupTS values so the user can understand why the restore is blocked.

### What did you see instead?

BR reports:

```text
found CDC changefeed(s): cluster/namespace: default/default changefeed(s): [...], please remove changefeed(s) before restore
```

This message is misleading because it implies that the restore is blocked simply because a changefeed exists and that the changefeed must be removed.

However, starting from BR v8.2.0, the documented behavior is:

* **BR v8.2.0 and later:** restore is blocked if a changefeed exists and its CheckpointTS is earlier than the BackupTS.
* **BR before v8.2.0:** restore is blocked if there is any active TiCDC changefeed.

The current error message appears to still reflect the pre-v8.2.0 behavior.

### Suggested improvement

Please update the error message to describe the actual blocking condition.

For example:

```text
Restore is blocked because TiCDC changefeed "..." has CheckpointTS < BackupTS.
Please advance, pause/remove, or otherwise handle the changefeed before retrying the restore.
```

It would also be useful to include the actual `CheckpointTS` and `BackupTS` values in the message.

### Additional context

The current wording is especially confusing when the changefeed is in an error/stuck state, because the user may not understand that the stale CheckpointTS is the reason BR refuses to proceed.

Contributor guide

Open the contributing guide

Research direction

Start at the BR restore path that checks existing TiCDC changefeeds, then trace how CheckpointTS and BackupTS are compared. Reproduce or test the blocked-restore case with a stuck changefeed and verify that the error identifies the stale CheckpointTS condition and includes both timestamp values when available.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
databases, distributed-systems
Issue type
Bug
Difficulty
4/5
Estimated time
3-5 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
55/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.