Motivation

PulsarAuthorizationProvider#validateTenantAdminAccess throws RestException(404, "Tenant does not exist") from inside thenCompose, and the exceptionally handler chained onto that same stage catches it. That handler only special-cases MetadataStoreException.NotFoundException, so the self-thrown 404 falls through to log.error("Failed to get tenant", cause).

Every request naming a tenant that does not exist therefore produces an ERROR line with a stack trace. A lookup is enough to trigger it, so a single misconfigured client pointed at a cluster that does not host its tenant can flood a healthy broker — roughly 1000 ERROR lines in 10 minutes from one client, on a broker with nothing wrong with it.

A tenant that does not exist is a client error, not a broker fault: any client can trigger it by mistyping a tenant name, and ServerCnx already reports the rejection at its own level.

MultiRolesTokenAuthorizationProvider overrides the method and carries an identical copy of the bug.

Modifications

• Move the exceptionally handler onto getTenantAsync(), the stage that can actually fail, and perform the presence check after it. The "tenant does not exist" rejection then has no error handler downstream.
• Map MetadataStoreException.NotFoundException to an empty Optional so both "tenant is missing" paths converge on the same 404.
• Use FutureUtil.unwrapCompletionException instead of ex.getCause(). Attached directly to getTenantAsync(), the exception is no longer wrapped in a CompletionException.
• Apply the same change to MultiRolesTokenAuthorizationProvider.

Genuine metadata store failures are still logged at ERROR. Client-visible behaviour is unchanged: the previous code rethrew new RestException(cause), which preserved the 404 response, so the status, message and ErrorData entity are identical.

Verifying this change

• Make sure that the change passes the CI checks.

This change added tests and can be verified as follows:

• Added PulsarAuthorizationProviderTest with three tests: one on validateTenantAdminAccess, one on allowTopicOperationAsync with TopicOperation.LOOKUP (the path an actual lookup takes), and one asserting that a metadata store failure is still logged at ERROR, which guards the fix from over-reaching.
• Added an equivalent test to MultiRolesTokenAuthorizationProviderTest.
• Added LogCapture, a Log4j2 appender that captures a single logger's events so the tests can assert on the level a condition is reported at.
• With the production change reverted, the three "must not be logged at ERROR" tests fail and the metadata-store-failure test still passes.

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