+1. It looks like there's no problem. Thanks, Sinan
PengHui Li <[email protected]> 于2026年10月24日周六 01:10写道： > +1 > > Thanks for driving the improvement > > Regards, > Penghui > > On Thu, Oct 22, 2026 at 7:53 AM void-ptr974 via dev <[email protected] > > > wrote: > > > Hi Pulsar community, > > > > I would like to start a discussion on PIP-497: Subscription-scoped > > internal statistics for persistent topics. > > > > Today, diagnosing a single subscription cursor requires fetching the > > complete topic-level internalStats response. That response includes all > > managed-ledger cursors and unrelated topic-level internal state, and > > individuallyDeletedMessages can make it especially large. The goal of > this > > PIP is to provide the same existing cursor diagnostics with a narrower > > request and response scope. > > > > The proposal is to: > > > > - add subscription-scoped REST, Java Admin, and pulsar-admin topics > access; > > - reuse the existing ManagedLedgerInternalStats.CursorStats contract > > without adding new cursor fields; > > - omit individuallyDeletedMessages by default and expose it through an > > includeIndividualDeletedMessages option; > > - support both a non-partitioned topic or explicit partition and a > > partitioned base topic; > > - return independent per-partition results with explicit partial failures > > instead of inventing an aggregated cursor position; and > > - keep the operation read-only and use the existing > > TopicOperation.GET_STATS authorization model. > > > > The main points on which I would appreciate feedback are: > > > > 1. Should the first version provide broker-side fan-out for partitioned > > topics, or require callers to query explicit partitions? > > 2. Is a dedicated subscription resource preferable to adding filtering > > semantics to the existing topic-level internalStats resource? > > 3. Should the potentially large individuallyDeletedMessages value be > > opt-in, or should the new endpoint preserve full parity by default? > > 4. Is GET_STATS the appropriate authorization model, or should this be > > tied to subscription-level consume permission? > > > > The proposal intentionally does not add a generic API for arbitrary > > internal cursor names. Replication, deduplication, and transaction > cursors > > have different semantics and may need component-specific diagnostics in > > separate proposals. > > > > PIP draft: > > https://github.com/apache/pulsar/pull/27014 > > > > Motivating prototype (the API shape may differ from the current PIP > draft): > > https://github.com/apache/pulsar/pull/27010 > > > > Feedback is welcome in this thread. Inline comments on the draft PR are > > also appreciated. > > > > Thanks, > > void-ptr974 > > >
