apache/pulsar · error · RestException

The replication cluster does not provide TLS encrypted servi

Error message

The replication cluster does not provide TLS encrypted service

What it means

A 412 PRECONDITION_FAILED thrown when deleting a global namespace whose sole remaining replication cluster is a different cluster: the broker tries to redirect the delete request to that cluster over TLS, but the remote cluster's cluster metadata has no serviceUrlTls configured. The delete cannot be forwarded securely, so it aborts.

Source

Thrown at pulsar-broker/src/main/java/org/apache/pulsar/broker/admin/impl/NamespacesBase.java:512

                                throw new RestException(Status.PRECONDITION_FAILED,
                                    "Cannot delete the global namespace " + nsName + ". There are still more than "
                                    + "one replication clusters configured or replication clusters is empty.");
                            }
                            if (!cluster.equals(config().getClusterName())) {
                                // the only replication cluster is other cluster, redirect
                                return clusterResources().getClusterAsync(cluster)
                                        .thenCompose(replClusterDataOpt -> {
                                            ClusterData replClusterData = replClusterDataOpt
                                                    .orElseThrow(() -> new RestException(Status.NOT_FOUND,
                                                            "Cluster " + cluster + " does not exist"));
                                            URL replClusterUrl;
                                            try {
                                                if (!replClusterData.isBrokerClientTlsEnabled()) {
                                                    replClusterUrl = new URL(replClusterData.getServiceUrl());
                                                } else if (StringUtils.isNotBlank(replClusterData.getServiceUrlTls())) {
                                                    replClusterUrl = new URL(replClusterData.getServiceUrlTls());
                                                } else {
                                                    throw new RestException(Status.PRECONDITION_FAILED,
                                                    "The replication cluster does not provide TLS encrypted service");
                                                }
                                            } catch (MalformedURLException checkedEx) {
                                                throw new RestException(checkedEx);
                                            }
                                            URI redirect = UriBuilder.fromUri(uri.getRequestUri())
                                                    .host(replClusterUrl.getHost())
                                                    .port(replClusterUrl.getPort())
                                                    .replaceQueryParam("authoritative", false).build();
                                                log.debug()
                                                        .attr("redirect", redirect)
                                                        .attr("cluster", cluster)
                                                        .log("Redirecting the rest call");
                                                        throw new WebApplicationException(
                                                                Response.temporaryRedirect(redirect)
                                                                        .build());
                                        });
                            }

View on GitHub (pinned to 820761864e)

Solutions

1. Update the remote cluster metadata to include a TLS service URL: PUT /admin/v2/clusters/{cluster} with serviceUrlTls set (e.g. https://broker:8443).
2. Alternatively set brokerClientTlsEnabled=false for that cluster metadata if the redirect should use the plain service URL (only if acceptable security-wise).
3. Delete the namespace directly on the owning cluster instead of being redirected.
4. Audit all cluster metadata entries with GET /admin/v2/clusters to confirm serviceUrlTls is populated wherever TLS is enabled.

Example fix

// before
curl -X PUT http://broker:8080/admin/v2/clusters/cluster-b -d '{"serviceUrl":"http://b:8080","brokerClientTlsEnabled":true}'

// after
curl -X PUT http://broker:8080/admin/v2/clusters/cluster-b -d '{"serviceUrl":"http://b:8080","serviceUrlTls":"https://b:8443","brokerClientTlsEnabled":true}'

const clusterData = await admin.clusters().getCluster(remoteCluster);
if (clusterData.brokerClientTlsEnabled && !clusterData.serviceUrlTls) {
  throw new Error(`cluster ${remoteCluster} lacks serviceUrlTls; fix metadata before namespace delete`);
}

try {
  await admin.namespaces().deleteNamespace(tenant, ns);
} catch (e) {
  if (e.getStatusCode() === 412 && /TLS/.test(e.getMessage())) {
    // update cluster metadata with serviceUrlTls, then retry
  } else throw e;
}

When it happens

Trigger: DELETE /admin/v2/namespaces/{tenant}/{namespace} on cluster A where the only remaining replication cluster B has brokerClientTlsEnabled=true but an empty/blank serviceUrlTls in its cluster metadata; the broker builds the redirect URL in precheckWhenDeleteNamespace and fails.

Common situations: Clusters configured with TLS-secured brokers but cluster metadata created before TLS was enabled, leaving serviceUrlTls blank; operators migrating clusters to HTTPS-only and forgetting to update cluster metadata; mixed TLS/non-TLS multi-cluster deployments.

Understand the failure class

• SSL/TLS and certificate errors — how TLS handshakes and certificate validation fail.

Related errors

• Cannot delete the global namespace ${nsName}. There are stil
• Cannot delete the global namespace ${namespaceName}. There a
• Local cluster is not part of replicate cluster list
• Peer cluster %s data not found
• Failed to acquire TLS material for purpose ${purpose}

AI-assisted analysis of apache/pulsar@820761864e (2026-09-06). Data as JSON: /api/errors/da039fde5a99fc90. Report an issue: GitHub.