Hi team, Bumping this thread for anyone who joined or subscribed after the original vote was sent out.
The vote is still open. Please cast your vote PIP PR: https://github.com/apache/pulsar/pull/27140 Thanks, Pruthviraj On Thu, Oct 29, 2026 at 1:48 PM Nikhil Sharma <[email protected]> wrote: > +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 >> >
