pd-ctl: TestScheduler can race with scheduling service synchronization
- Dominant language
- Go
- Stars
- 1.2k
- Forks
- 783
- Avg merge
- 5d 21h
- Merged PRs (30d)
- 36
Description
## Flaky Test
### Which jobs are failing
Affected test: `TestSchedulerTestSuite/TestScheduler` in `tools/pd-ctl/tests/scheduler`, under the Tools Test job in microservice mode.
### CI link
The original failing run is not recorded in #11246. The matching Tools Test on the proposed fix passed with race detection enabled:
https://github.com/tikv/pd/actions/runs/34857968940/job/104027701875
### Reason for failure (if possible)
The test creates `evict-leader-scheduler` for store 1 and immediately invokes `scheduler add evict-leader-scheduler 2`.
In microservice mode, creation returns after PD persists the scheduler configuration, while `scheduler show` reads the scheduling service's asynchronously synchronized scheduler list. If the second command reads that list before synchronization finishes, it takes the create path again instead of updating the existing scheduler, violating the test's expected store-update result.
### Anything else
#11246 waits until the scheduling service lists the newly created scheduler before issuing the dependent update. This issue tracks that creation-to-update race.
Contributor guide
Research direction
Start with tools/pd-ctl/tests/scheduler and the TestSchedulerTestSuite/TestScheduler case. Read the synchronization wait used by #11246, then run the affected Tools Test in microservice mode with race detection. Done means the create-then-update sequence consistently observes the existing scheduler and the test passes without a race.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli, testing
- Issue type
- Bug
- Difficulty
- 2/5
- Estimated time
- 1-3 hours
- Activity status
- Active
- Clarity
- Clearly specified
- Newbie friendliness
- 78/100