apache/pulsar · error · java.lang.UnsupportedOperationException
Another partition exists for [${topicName}].
Error message
Another partition exists for [${topicName}]. What it means
When deleting a partitioned topic, the broker deletes each partition first and then removes the partitioned-topic metadata. Before deleting metadata it checks whether any partition still exists; if at least one partition check returns true, deletion is aborted with UnsupportedOperationException because removing the parent metadata while partitions remain would orphan them. The error protects the invariants of partitioned-topic bookkeeping in metadata storage.
Source
Thrown at pulsar-broker/src/main/java/org/apache/pulsar/broker/service/persistent/PersistentTopic.java:3836
for (int i = 0; i < metadata.partitions; i++) {
persistentTopicExists.add(brokerService.getPulsar()
.getPulsarResources().getTopicResources()
.persistentTopicExists(topicName.getPartition(i)));
}
List<CompletableFuture<Boolean>> unmodifiablePersistentTopicExists =
Collections.unmodifiableList(persistentTopicExists);
return FutureUtil.waitForAll(unmodifiablePersistentTopicExists)
.thenCompose(unused -> {
// make sure all sub partitions were deleted after all future complete
Optional<Boolean> anyExistPartition = unmodifiablePersistentTopicExists
.stream()
.map(CompletableFuture::join)
.filter(topicExist -> topicExist)
.findAny();
if (anyExistPartition.isPresent()) {
log.info("Delete topic metadata failed because "
+ "another partition exists");
throw new UnsupportedOperationException(
String.format("Another partition exists for [%s].",
topicName));
} else {
try {
return brokerService.getPulsar().getAdminClient().topics()
.deletePartitionedTopicAsync(topicName.toString());
} catch (PulsarServerException e) {
log.info()
.exception(e)
.log("Delete topic metadata failed due to failed to"
+ "get internal admin client.");
return CompletableFuture.failedFuture(e);
}
}
});
}))
);
}View on GitHub (pinned to 820761864e)
Solutions
- Wait for partition deletion to fully complete (all partitions removed from all brokers) and retry deletePartitionedTopic
- Call deletePartitionedTopic with deleteSchema=false as appropriate and ensure no producers/consumers are recreating partitions, then retry
- Force-delete remaining individual partitions first (topics().delete per partition), then delete the partitioned topic metadata
- Check broker logs ('Delete topic metadata failed because another partition exists') and clear stale topic list caches if partitions are actually gone
Example fix
// before admin.topics().deletePartitionedTopic(topic); // may fail if partitions linger // after await().atMost(30, SECONDS).until(() -> admin.topics().getPartitionedTopicMetadata(topic).partitions > 0 ? admin.topics().getList(namespace).stream().noneMatch(t -> t.startsWith(topic + PersistentTopicInternalTopics.PARTITIONED_TOPIC_SUFFIX) && !t.equals(topic)) : true); admin.topics().deletePartitionedTopic(topic);
Defensive patterns
Strategy: retry
Validate before calling
boolean allPartitionsGone(String partitionedTopic, int partitions) throws PulsarAdminException {
for (int i = 0; i < partitions; i++) {
try {
admin.topics().getStats(partitionedTopic + "-partition-" + i);
return false; // partition still exists
} catch (PulsarAdminException.NotFoundException e) { /* gone */ }
}
return true;
} Try / catch
try {
admin.topics().deletePartitionedTopic(topic);
} catch (UnsupportedOperationException e) {
if (e.getMessage().contains("Another partition exists")) {
// wait for partitions to disappear, then retry
Thread.sleep(5000);
admin.topics().deletePartitionedTopic(topic);
} else throw e;
} Prevention
- Stop producers/consumers before deleting partitioned topics
- Delete partitions first and verify they are gone before removing metadata
- Be aware of broker topic-list caching delays after partition deletion
When it happens
Trigger: Calling admin topics().deletePartitionedTopic() (or internal metadata delete) after the per-partition existence checks found at least one partition still present — e.g. partial partition deletion left partitions behind, or the existence check futures resolved true due to stale caches/timing.
Common situations: Retrying a previously failed delete where some partitions were removed; topic list/lookup caches briefly reporting the partitions as existing; delete of a partitioned topic whose partitions are being recreated concurrently by a producer; namespace/topic policy propagation delays in geo-replicated clusters.
Related errors
- The topic has a max partition index of %d, the number of par
- Package Management Service is not enabled in the broker.
- entryFilterNames can't be empty. To remove entry filters use
- The offloadPolicies must be specified for namespace offload.
- The driver is not supported, support value: ${supportedDrive
AI-assisted analysis of apache/pulsar@820761864e (2026-09-06).
Data as JSON: /api/errors/6d13ab9bbcf68225.
Report an issue: GitHub.