Skip to content

feat(inkless): POD-2456 Enable offset fetch in consolidating partitions - #594

Merged
jeqo merged 3 commits into
mainfrom
svv/ts-unification-list-offsets
May 19, 2026
Merged

feat(inkless): POD-2456 Enable offset fetch in consolidating partitions#594
jeqo merged 3 commits into
mainfrom
svv/ts-unification-list-offsets

Conversation

@viktorsomogyi

Copy link
Copy Markdown
Contributor

Enable list offsets API for consolidating partitions. When they fetch offsets, the decision should be similar to what is already done for diskless partitions that have classic log tails.

@viktorsomogyi
viktorsomogyi requested a review from Copilot May 13, 2026 12:26

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Enables ListOffsets routing support for consolidating diskless topics by extending DisklessFetchOffsetRouter to recognize consolidation-enabled topics and applying routing decisions similar to existing hybrid (classic+diskless) behavior.

Changes:

  • Add a consolidation-enabled flag to DisklessFetchOffsetRouter and wire it from ReplicaManager config.
  • Update routing logic to treat consolidating diskless topics as hybrid and allow follower access on the classic leg.
  • Add unit tests covering consolidating-topic routing scenarios, including migration-pending and classic-only timestamps.

Reviewed changes

Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.

File Description
core/src/main/scala/kafka/server/DisklessFetchOffsetRouter.scala Adds consolidation-aware routing decisions for ListOffsets and follower allowance in classic leg.
core/src/main/scala/kafka/server/ReplicaManager.scala Wires disklessRemoteStorageConsolidationEnabled into the router constructor.
core/src/test/scala/unit/kafka/server/DisklessFetchOffsetRouterTest.scala Adds tests for consolidating-topic ListOffsets routing behavior and updates router construction helper.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread core/src/main/scala/kafka/server/DisklessFetchOffsetRouter.scala Outdated
Comment thread core/src/main/scala/kafka/server/DisklessFetchOffsetRouter.scala Outdated
Comment thread core/src/main/scala/kafka/server/DisklessFetchOffsetRouter.scala
@viktorsomogyi
viktorsomogyi force-pushed the svv/ts-unification-local-lso branch 3 times, most recently from 7e2313e to ca597a3 Compare May 13, 2026 14:24
@viktorsomogyi
viktorsomogyi force-pushed the svv/ts-unification-list-offsets branch 2 times, most recently from a078cee to 7934455 Compare May 14, 2026 08:51
@viktorsomogyi
viktorsomogyi marked this pull request as ready for review May 14, 2026 12:37
jeqo
jeqo previously approved these changes May 18, 2026

@jeqo jeqo left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, just a suggestion on a potential test case to add.

Base automatically changed from svv/ts-unification-local-lso to main May 19, 2026 08:31
@giuseppelillo
giuseppelillo dismissed jeqo’s stale review May 19, 2026 08:31

The base branch was changed.

viktorsomogyi and others added 3 commits May 19, 2026 14:11
Use local log's log start offset instead of the one that is stored in
the diskless coordinator. This is needed for consolidating partitions
as they expect that the log start at the beginning of the already
consolidated log that is in UnifiedLog.

Fetching with FetchHandler returns the log_start_offset from the coordinator
which is actually the diskless start offset. If we pass this on, then
ReplicaManager will believe that log_start_offset is the first offset and
therefore enforces retention.
Instead of this behavior we should use the local log start offset to
properly respect the offset boundaries and retention.
Enable list offsets API for consolidating partitions. When they fetch offsets,
the decision should be similar to what is already done for diskless partitions
that have classic log tails.
…rTest.scala

Co-authored-by: Jorge Esteban Quilcate Otoya <jorge.quilcate@aiven.io>
@viktorsomogyi
viktorsomogyi force-pushed the svv/ts-unification-list-offsets branch from 0e3b86b to 7d817a1 Compare May 19, 2026 12:11
@viktorsomogyi
viktorsomogyi requested a review from jeqo May 19, 2026 12:56
@jeqo
jeqo merged commit ffab594 into main May 19, 2026
4 checks passed
@jeqo
jeqo deleted the svv/ts-unification-list-offsets branch May 19, 2026 13:02
giuseppelillo pushed a commit that referenced this pull request May 28, 2026
…ns (#594)

* fix(inkless): POD-1965 Use local log start in DisklessLeaderEndPoint

Use local log's log start offset instead of the one that is stored in
the diskless coordinator. This is needed for consolidating partitions
as they expect that the log start at the beginning of the already
consolidated log that is in UnifiedLog.

Fetching with FetchHandler returns the log_start_offset from the coordinator
which is actually the diskless start offset. If we pass this on, then
ReplicaManager will believe that log_start_offset is the first offset and
therefore enforces retention.
Instead of this behavior we should use the local log start offset to
properly respect the offset boundaries and retention.

* feat(inkless): POD-2456 Enable offset fetch in consolidating partitions

Enable list offsets API for consolidating partitions. When they fetch offsets,
the decision should be similar to what is already done for diskless partitions
that have classic log tails.

* Update core/src/test/scala/unit/kafka/server/DisklessFetchOffsetRouterTest.scala

Co-authored-by: Jorge Esteban Quilcate Otoya <jorge.quilcate@aiven.io>

---------

Co-authored-by: Jorge Esteban Quilcate Otoya <jorge.quilcate@aiven.io>
giuseppelillo pushed a commit that referenced this pull request May 29, 2026
…ns (#594)

* fix(inkless): POD-1965 Use local log start in DisklessLeaderEndPoint

Use local log's log start offset instead of the one that is stored in
the diskless coordinator. This is needed for consolidating partitions
as they expect that the log start at the beginning of the already
consolidated log that is in UnifiedLog.

Fetching with FetchHandler returns the log_start_offset from the coordinator
which is actually the diskless start offset. If we pass this on, then
ReplicaManager will believe that log_start_offset is the first offset and
therefore enforces retention.
Instead of this behavior we should use the local log start offset to
properly respect the offset boundaries and retention.

* feat(inkless): POD-2456 Enable offset fetch in consolidating partitions

Enable list offsets API for consolidating partitions. When they fetch offsets,
the decision should be similar to what is already done for diskless partitions
that have classic log tails.

* Update core/src/test/scala/unit/kafka/server/DisklessFetchOffsetRouterTest.scala

Co-authored-by: Jorge Esteban Quilcate Otoya <jorge.quilcate@aiven.io>

---------

Co-authored-by: Jorge Esteban Quilcate Otoya <jorge.quilcate@aiven.io>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants