br: Misleading BR error message when restore is blocked by TiCDC CheckpointTS
- 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
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