apache/pulsar · error · RestException

Bundle range %s not found

Error message

Bundle range %s not found

What it means

This error is thrown by the namespace admin API when resolving a bundle for a namespace (e.g. via the 'get bundle range by name' / split/unload path). The broker searched for a bundle whose range matches the requested bundle name using findHotBundleAsync, got a null result, and translated that into an HTTP 404. It means no bundle with the given range is currently owned/configured for this namespace.

Source

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

                                }
                                return new TopicHashPositions(namespaceName.toString(), bundleRange,
                                        topicHashPositions);
                            });
                });
    }

    private CompletableFuture<String> getBundleRangeAsync(String bundleName) {
        CompletableFuture<NamespaceBundle> future;
        if (BundleType.LARGEST.toString().equals(bundleName)) {
            future = findLargestBundleWithTopicsAsync(namespaceName);
        } else if (BundleType.HOT.toString().equals(bundleName)) {
            future = findHotBundleAsync(namespaceName);
        } else {
            return CompletableFuture.completedFuture(bundleName);
        }
        return future.thenApply(nsBundle -> {
            if (nsBundle == null) {
                throw new RestException(Status.NOT_FOUND,
                        String.format("Bundle range %s not found", bundleName));
            }
            return nsBundle.getBundleRange();
        });
    }

    private CompletableFuture<NamespaceBundle> findLargestBundleWithTopicsAsync(NamespaceName namespaceName) {
        return pulsar().getNamespaceService().getNamespaceBundleFactory()
                .getBundleWithHighestTopicsAsync(namespaceName);
    }

    private CompletableFuture<NamespaceBundle> findHotBundleAsync(NamespaceName namespaceName) {
        return pulsar().getNamespaceService().getNamespaceBundleFactory()
                .getBundleWithHighestThroughputAsync(namespaceName);
    }

    protected void internalSetPublishRate(PublishRate maxPublishMessageRate) {
        validateSuperUserAccess();

View on GitHub (pinned to 820761864e)

Solutions

  1. List the namespace's current bundles (GET /namespaces/{ns}/bundles or namespaces properties) and use one of the returned bundleRange values
  2. Re-check the bundle range string format: it must be like '0x00000000_0x08000000' matching the namespace boundaries
  3. If bundles were changed recently, re-fetch boundaries instead of caching them
  4. Ensure you are querying the same cluster/registry where the bundle exists

Example fix

// before
String range = "0x00000000_0x40000000"; // stale cached range
admin.namespaces().deleteBundle("my-tenant/my-ns", range);
// after
List<String> bundles = admin.namespaces().getBundles("my-tenant/my-ns").getBoundaries();
String range = bundles.get(0) + "_" + bundles.get(1); // derive from live data
admin.namespaces().deleteBundle("my-tenant/my-ns", range);
Defensive patterns

Strategy: validation

Validate before calling

String[] parts = bundleRange.split("_");
if (parts.length != 2 || !parts[0].startsWith("0x") || !parts[1].startsWith("0x")) {
    throw new IllegalArgumentException("Invalid bundle range format: " + bundleRange);
}
boolean exists = admin.namespaces().getBundles(ns).getBoundaries().contains(parts[0]);
if (!exists) throw new IllegalArgumentException("Bundle not present in namespace: " + bundleRange);

Try / catch

try {
    admin.namespaces().deleteBundle(ns, bundleRange);
} catch (PulsarAdminException.NotFoundException e) {
    log.warn("Bundle {} not found in {}, refreshing bundle list", bundleRange, ns);
    admin.namespaces().getBundles(ns); // re-sync and retry with a valid range
}

Prevention

When it happens

Trigger: Calling an admin endpoint that takes a bundle range (e.g. DELETE /namespaces/{ns}/{bundle} or unload/split endpoints) with a bundle range string like '0x00000000_0x08000000' that does not exist in the namespace's bundle data; the namespace's bundles were re-split or recreated so the old range is gone; or a typo/format mismatch in the bundle range parameter.

Common situations: Scripts that cached bundle ranges from a previous configuration and the namespace was later unbundled or re-split; clients of a different cluster where bundle assignment differs; passing a topic's bundle range from one namespace to another; using default bundle count (no splits) when the script assumes split bundles.

Related errors


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