fix(inkless:switch): Init Diskless Log on Control Plane on leader changes#603
Merged
giuseppelillo merged 2 commits intoMay 21, 2026
Merged
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
This PR updates the diskless classic→diskless migration flow so that Control Plane diskless init is re-driven when leadership changes, even if the committing metadata (classicToDisklessStartOffset / producer states) was already processed while the broker was a follower.
Changes:
- Trigger Control Plane init not only when
classicToDisklessStartOffsetis newly committed, but also when the broker becomes leader for a partition that already has committed diskless-init metadata. - Refactor
ReplicaManager’s Control Plane init traversal to operate on the broker’s locally-leading partitions fromTopicsDelta.localChanges(...). - Add unit tests covering leader failover re-drive behavior and ensuring same-leader partition changes do not re-drive Control Plane init.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| core/src/main/scala/kafka/server/ReplicaManager.scala | Expands Control Plane init triggering conditions to include leader changes and scopes evaluation to local leader partitions. |
| core/src/test/scala/unit/kafka/server/metadata/DisklessSwitchFlowTest.scala | Adds coverage for leader failover re-drive and guards against redundant re-drive on same-leader changes. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
2785e58 to
5b2004a
Compare
…nges Currently diskless init on Control Plane is only executed by leaders when they see a change in classicToDisklessStartOffset from <0 to >=0, which means that the offset was just committed to the metadata log. In case the init on control plane was not successful and a new leader is elected, the new leader will not retry the init in cases where the metadata record that committed classicToDisklessStartOffset was already process previously by the new leader. Change this behavior so that diskless init on Control Plane is done also when there's a leader change.
5b2004a to
68b64cb
Compare
jeqo
reviewed
May 21, 2026
jeqo
left a comment
Contributor
There was a problem hiding this comment.
LGTM, just a couple of minor suggestions.
jeqo
approved these changes
May 21, 2026
giuseppelillo
added a commit
that referenced
this pull request
May 28, 2026
…nges (#603) * fix(inkless:switch): Init Diskless Log on Control Plane on leader changes Currently diskless init on Control Plane is only executed by leaders when they see a change in classicToDisklessStartOffset from <0 to >=0, which means that the offset was just committed to the metadata log. In case the init on control plane was not successful and a new leader is elected, the new leader will not retry the init in cases where the metadata record that committed classicToDisklessStartOffset was already process previously by the new leader. Change this behavior so that diskless init on Control Plane is done also when there's a leader change. * Fix suggestions
giuseppelillo
added a commit
that referenced
this pull request
May 29, 2026
…nges (#603) * fix(inkless:switch): Init Diskless Log on Control Plane on leader changes Currently diskless init on Control Plane is only executed by leaders when they see a change in classicToDisklessStartOffset from <0 to >=0, which means that the offset was just committed to the metadata log. In case the init on control plane was not successful and a new leader is elected, the new leader will not retry the init in cases where the metadata record that committed classicToDisklessStartOffset was already process previously by the new leader. Change this behavior so that diskless init on Control Plane is done also when there's a leader change. * Fix suggestions
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Currently diskless init on Control Plane is only executed by leaders when they see a change in
classicToDisklessStartOffsetfrom <0 to >=0, which means that the offset was just committed to the metadata log. In case the init on control plane was not successful and a new leader is elected, the new leader will not retry the init in cases where the metadata record that committedclassicToDisklessStartOffsetwas already processed previously by the new leader.Change this behavior so that diskless init on Control Plane is done also when there's a leader change.