*+1 (binding)* The proposal looks good to me. Adding a default overload to the Topics interface is a clean approach to supporting position-aware peeking while preserving source and binary compatibility with existing implementations and callers. Thanks & Regards, Jaswanth Malasani
On Thu, Oct 29, 2026 at 6:58 PM Pruthviraj Chandru via dev < [email protected]> wrote: > 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 > >> > > >
