+1 (non-binding)

The proposal looks solid. Using a default overload on the `Topics`
interface is the right compatibility strategy here — it allows adding
position-aware peeking while maintaining complete source and binary
compatibility for existing implementors and callers.

A few quick observations:
- **Client-side validation**: Validating `messagePosition >= 1` upfront
with an `IllegalArgumentException` is a good practice to prevent
unnecessary network roundtrips for invalid inputs.

On Wed, Oct 28, 2026 at 9:41 PM Pruthviraj Chandru via dev <
[email protected]> wrote:

> Hi Pulsar community,
>
> I would like to revive the discussion on PIP-482: Peek messages from topic
> subscription with messagePosition.
>
> Today, Topics.peekMessages / peekMessagesAsync in the Java admin client
> hardcode messagePosition = 1, so callers can only inspect messages from the
> head of a subscription backlog. The underlying REST endpoint already
> accepts an arbitrary position:
> http
>
> GET
> /admin/v3/persistent/{tenant}/{namespace}/{topic}/subscription/{subName}/position/{messagePosition}
>
> The most common impact is admin UI pagination — showing the 91st–100th
> backlog messages requires fetching and discarding the first 90, which is
> wasteful on both client and broker.
>
> The proposal is to:
>
>    - Add a position-aware default overload to the Topics interface — no new
>    abstract method and no server changes needed.
>    - Preserve full source and binary compatibility with all existing
>    peekMessages / peekMessagesAsync overloads.
>    - Validate messagePosition >= 1 at the client with a clear
>    IllegalArgumentException.
>    - Leave MessageId-based peek and a PeekOptions builder to future PIPs.
>
> The main point on which I would appreciate feedback is:
>
>    1. Is the default overload approach the right compatibility strategy, or
>    would a different API shape be preferred?
>
> PIP draft PR: https://github.com/apache/pulsar/pull/27140
>
> Feedback is welcome in this thread or as inline comments on the draft PR.
>
> Thanks,
> Pruthviraj
>

Reply via email to