dispatcher manager: heartbeat collector should validate message source maintainer
Nobody has claimed this yet.
- Dominant language
- Go
- Stars
- 56
- Forks
- 63
- Avg merge
- 2d 20h
- Merged PRs (30d)
- 34
Description
Problem
downstreamadapter/dispatchermanager/HeartBeatCollector.RecvMessages currently routes and handles incoming maintainer->DM control messages by changefeed ID, but does not validate msg.From against the current maintainer ID tracked by the corresponding dispatcher manager.
Risk
During maintainer switch windows, stale messages from an old maintainer can be accepted and executed. This is a control-plane consistency risk and affects more than recover path, including schedule/merge/heartbeat response and other downstream control messages.
Expected Behavior
For each changefeed-scoped control message, DM should only accept messages from the current maintainer of that changefeed. Stale-source messages should be dropped with warning logs.
Suggested Fix
- Carry source node in message wrappers pushed from
RecvMessagesto handlers. - In handler
Handle(...), compare source withdispatcherManager.GetMaintainerID(). - On mismatch: log and drop.
Scope
At least cover high-risk control messages:
TypeScheduleDispatcherRequestTypeMergeDispatcherRequestTypeHeartBeatResponse
(Optionally extend to checkpoint/redo control messages for full consistency.)
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start in downstreamadapter/dispatchermanager/HeartBeatCollector.RecvMessages and trace the wrappers and Handle(...) implementations for TypeScheduleDispatcherRequest, TypeMergeDispatcherRequest, and TypeHeartBeatResponse. Verify that each changefeed-scoped message is checked against dispatcherManager.GetMaintainerID(), with mismatches logged as warnings and dropped.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- distributed-systems
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100