[fix][broker] Fix getEstimatedSizeSinceMarkDeletePosition throw IllegalArgumentException

[Technoboy-]

Motivation

2026-07-04T08:12:28,153+0000 [pulsar-compaction-monitor-26-1] WARN  org.apache.pulsar.broker.service.persistent.PersistentTopic - [persistent://email/org-74/__change_events-partition-0] Error getting policies and skipping compaction check
java.lang.IllegalArgumentException: Invalid range: (25257774:-1..25234514:0]
	at com.google.common.collect.Range.<init>(Range.java:363)
	at com.google.common.collect.Range.create(Range.java:161)
	at com.google.common.collect.Range.openClosed(Range.java:210)
	at org.apache.bookkeeper.mledger.impl.ManagedCursorImpl.getEstimatedSizeSinceMarkDeletePosition(ManagedCursorImpl.java:1306)
--
	at org.apache.pulsar.common.util.SingleThreadNonConcurrentFixedRateScheduler$ScheduledFutureTask.run(SingleThreadNonConcurrentFixedRateScheduler.java:371)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
	at io.netty.util.concurrent.FastThreadLocalRunnable.run(FastThreadLocalRunnable.java:30)
	at java.base/java.lang.Thread.run(Unknown Source)
2026-07-04T08:12:28,159+0000 [pulsar-compaction-monitor-26-1] WARN  org.apache.pulsar.broker.service.persistent.PersistentTopic - [persistent://email/org-87/__change_events-partition-0] Error getting policies and skipping compaction check
java.lang.IllegalArgumentException: Invalid range: (25519982:-1..25495087:0]
	at com.google.common.collect.Range.<init>(Range.java:363)
	at com.google.common.collect.Range.create(Range.java:161)
	at com.google.common.collect.Range.openClosed(Range.java:210)
	at org.apache.bookkeeper.mledger.impl.ManagedCursorImpl.getEstimatedSizeSinceMarkDeletePosition(ManagedCursorImpl.java:1306)

Modifications

Verifying this change

• Make sure that the change passes the CI checks.

(Please pick either of the following options)

This change is a trivial rework / code cleanup without any test coverage.

(or)

This change is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

• Added integration tests for end-to-end deployment with large payloads (10MB)
• Extended integration test for recovery after broker failure

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment

[Copilot]

Pull request overview

Fixes a production warning where ManagedCursorImpl#getEstimatedSizeSinceMarkDeletePosition() could throw IllegalArgumentException when the cursor’s markDeletePosition is ahead of the ledger’s lastPosition (creating an invalid Guava Range), which caused compaction checks to be skipped.

Changes:

• Add an early-return guard in getEstimatedSizeSinceMarkDeletePosition() when markDeletePosition is null or >= lastPosition, preventing invalid Range construction.
• Reuse a single lastPosition snapshot when computing the backlog range for both deleted-message counting and entry counting.
• Add a unit test covering the “cursor markDeletePosition ahead of lastPosition” scenario.

Reviewed changes

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

File	Description
managed-ledger/src/main/java/org/apache/bookkeeper/mledger/impl/ManagedCursorImpl.java	Prevent invalid (markDelete..last] ranges by returning 0 when mark-delete is at/after last position; use a consistent lastPosition snapshot for range calculations.
managed-ledger/src/test/java/org/apache/bookkeeper/mledger/impl/ManagedCursorTest.java	Adds regression test ensuring estimated unacked size returns 0 (and doesn’t throw) when the cursor is ahead of the ledger last position.

[void-ptr974]

I think we should distinguish markDeletePosition == lastPosition from markDeletePosition > lastPosition.

The problematic case is when the cursor is ahead of the ledger last position, for example:

• markDeletePosition = 101:-1
• lastPosition = 100:9

This can happen when the cursor has consumed the previous ledger and has been advanced to the beginning of a new empty ledger. In that case, constructing (101:-1..100:9] is invalid, and returning 0 backlog is reasonable.

But markDeletePosition == lastPosition is a normal caught-up state. For example:

• write messages up to 100:9
• cursor marks delete at 100:9
• now markDeletePosition = 100:9 and lastPosition = 100:9

There is no backlog, so getEstimatedSizeSinceMarkDeletePosition() should return 0, not throw. With the current >= check, this equality case can enter the “ahead” branch and throw if the last ledger exists and is not empty.

Could we handle equality as 0 directly and only treat markDeletePosition > lastPosition as the special ahead-of-last-position case? A regression test for the caught-up case would also help.

[Technoboy-]

I think we should distinguish markDeletePosition == lastPosition from markDeletePosition > lastPosition.

The problematic case is when the cursor is ahead of the ledger last position, for example:

• markDeletePosition = 101:-1
• lastPosition = 100:9

This can happen when the cursor has consumed the previous ledger and has been advanced to the beginning of a new empty ledger. In that case, constructing (101:-1..100:9] is invalid, and returning 0 backlog is reasonable.

But markDeletePosition == lastPosition is a normal caught-up state. For example:

• write messages up to 100:9
• cursor marks delete at 100:9
• now markDeletePosition = 100:9 and lastPosition = 100:9

There is no backlog, so getEstimatedSizeSinceMarkDeletePosition() should return 0, not throw. With the current >= check, this equality case can enter the “ahead” branch and throw if the last ledger exists and is not empty.

Could we handle equality as 0 directly and only treat markDeletePosition > lastPosition as the special ahead-of-last-position case? A regression test for the caught-up case would also help.

Thanks for reviewing. addressed

[void-ptr974]

It looks like we currently only cover the markDeletePosition == lastPosition case in testEstimatedUnackedSizeWhenLatestLedgerIsEmpty. A regression case where the cursor has advanced to currentLedger:-1 while lastPosition is still in the previous ledger would also exercise isMarkDeletePositionOnEmptyCurrentLedger() and the invalid-range scenario addressed here.