[br] PiTR can report success after an AUTO_ID rebase failure and later overwrite restored rows
- Dominant language
- Go
- Stars
- 40.5k
- Forks
- 6.2k
- PR merge metrics
- PR metrics pending
Description
## Bug Report
### 1. Minimal reproduce step (Required)
**Environment**
TiDB master 231dad5225; AUTO_ID_CACHE=1; BR PiTR finalization; current source test path
**Steps**
Create an AUTO_ID_CACHE=1 table and initialize its auto-ID service. Model PiTR raw-KV replay by adding restored row id=2 and advancing persisted IncrementID without notifying the service. Enable the existing pkg/kv mockCommitErrorInNewTxn failpoint for the final rebase transaction. RebaseAutoIncrementIDForSepAutoIncTables returns nil; REPLACE INTO t(data) allocates id=2, returns affected_rows=2, and overwrites the restored row. Disable only the error and repeat for the matched GREEN.
### 2. What did you expect to see? (Required)
Any failure of the mandatory post-replay allocator repair must fail the restore or be retried until every affected table is synchronized before the cluster is returned to writes.
### 3. What did you see instead? (Required)
The helper logs a warning and returns nil. The next generated REPLACE reports last_insert_id=2 and row_count=2; fresh reads show id=2 changed from restored-two to replacement. With the same state and no error, rebase reaches 1004000, the next ID is 1004001, and id=2 is preserved.
### 4. What is your TiDB version? (Required)
TiDB master 231dad5225; AUTO_ID_CACHE=1; BR PiTR finalization; current source test path
Likely root cause and fix direction
**Likely root cause**
RebaseAutoIncrementIDForSepAutoIncTables treats each rebaseAutoIncrementIDForTable error as best effort even though this repair is the only step that closes the stale in-memory allocator state created by raw log replay. No later restore stage validates generated-ID disjointness.
**Fix direction**
Make per-table rebase failure terminal, or add bounded retry plus a final all-table closure check. Do not publish restore success while any required allocator repair remains unconfirmed.
Contributor guide
Research direction
Start at RebaseAutoIncrementIDForSepAutoIncTables and the rebaseAutoIncrementIDForTable path used during BR PiTR finalization. Reproduce the failure with the pkg/kv mockCommitErrorInNewTxn failpoint, then trace how the helper handles the error before the subsequent REPLACE INTO. Done means a failed mandatory rebase cannot report restore success, and the generated ID cannot overwrite a restored row.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, sql
- Domain
- databases
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 48/100