[feat][broker] PIP-452: Customizable topic listing of namespace with properties

[coderzc]

Fixes #xyz

Main Issue: #xyz

PIP: #xyz

Motivation

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

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository:

[BewareMyPower]

You don't have to copy so much code here, which does not focus on the key change. The only thing that matters is that what will replace the following existing code:

                        return getBrokerService().pulsar().getNamespaceService()
                                .getListOfUserTopics(namespaceName, mode)

[coderzc]

Simplified pseudocode

[BewareMyPower]

This design is a bit over-abstraction. IMO, the following design could be simpler and clearer.

public record TopicListingResult(List<String> topics, boolean filtered) {}

    /**
     * @return the future of the result, if it's empty, fall back to the built-in implementation to list all topics
     */
    default CompletableFuture<Optional<TopicListingResult>> interceptGetTopicsOfNamespace(

[BewareMyPower]

Since the built-in implementation is very simple that calls method directly on the NamespaceService, I think the fallback logic is unnecessary.

[coderzc]

Since we allow the configuration of multiple interceptors, the return here means that the result of current interception is not processed this method. If all the interceptors do not process the method, the default logic will be used.

In addition, the interception configuration is empty by default. In this case, we still need to fall back to the default logic.

[coderzc]

default CompletableFuture<Optional<TopicListingResult>> interceptGetTopicsOfNamespace()

Applied this suggestion

[Copilot]

Pull request overview

This PR introduces PIP-452, which proposes a design for customizable topic listing in Pulsar's GetTopicsOfNamespace command. The proposal aims to make topic discovery more flexible by allowing clients to pass context properties and enabling plugins to override the default metadata store scanning behavior.

Changes:

• Adds protocol extension to include properties field in CommandGetTopicsOfNamespace
• Introduces BrokerInterceptor interface method for custom topic listing logic
• Extends REST API and CLI to support properties parameter for topic listing

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.