You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@polaris.apache.org by "ayushtkn (via GitHub)" <gi...@apache.org> on 2026/08/24 02:22:02 UTC
[PR] Fix namespace creation rejecting its own default location [polaris]
ayushtkn opened a new pull request, #5357:
URL: https://github.com/apache/polaris/pull/5357
Creating a namespace without a location fails with `400` whenever a catalog's
`default-base-location` is nested inside an allowed location rather than being equal to one:
Namespace ns has a custom location, which is not enabled.
```
Expected a location in: [file:///tmp/x/ns/].
Got location: file:///tmp/x/warehouse/test-catalog/ns/]
```
The caller supplied no location at all, so the message is doubly misleading: the location it
rejects is the one the server itself just derived.
Two validations disagree about what "inside an allowed location" means. Catalog creation asks only
for containment โ `CatalogEntity.validateBaseLocationAgainstAllowedList` uses
`anyMatch(baseLocation::isChildOf)` โ so `default-base-location` may sit anywhere beneath an allowed
location. Namespace creation then demanded exact equality: `validateNamespaceLocation` built its
candidates from `getStorageConfigurationInfo().getAllowedLocations()` mapped to
`<allowedLocation>/<namespaceName>` and required set membership. But a namespace's location is
derived from the catalog's `default-base-location`, never from the allowed locations, so the two
only agree when `default-base-location` happens to equal an allowed location. With the common
layout โ allowed `s3://bucket/warehouse/`, `default-base-location` `s3://bucket/warehouse/mycat` โ
the catalog is created successfully and then every plain `CREATE NAMESPACE` fails.
`ALLOW_NAMESPACE_CUSTOM_LOCATION` defaults to `false`, so the check runs by default.
The sibling branch of the same method already does this correctly: when the parent is a namespace it
compares against the parent's actual resolved location. This makes the parent-catalog branch do the
same, deriving the expected location with `resolveLocationForPath`, which is the helper
`resolveNamespaceLocation` itself uses. The check can no longer drift from the derivation it
validates, and the existing null-default-base-location diagnostic in `baseLocation()` now covers
this path too.
## Checklist
- [ ] ๐ก๏ธ Don't disclose security issues! (contact security@apache.org)
- [ ] ๐ Clearly explained why the changes are needed, or linked related issues: Fixes #
- [ ] ๐งช Added/updated tests with good coverage, or manually tested (and explained how)
- [ ] ๐ก Added comments for complex logic
- [ ] ๐งพ Updated `CHANGELOG.md` (if needed)
- [ ] ๐ Updated documentation in `site/content/in-dev/unreleased` (if needed)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Fix namespace creation rejecting its own default location [polaris]
Posted by "flyrain (via GitHub)" <gi...@apache.org>.
flyrain commented on code in PR #5357:
URL: https://github.com/apache/polaris/pull/5357#discussion_r3888152850
##########
runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/LocalIcebergCatalog.java:
##########
Review Comment:
The current name is too board. Can we rename it to `validateNamespaceUsesDefaultLocation()`?
##########
CHANGELOG.md:
##########
@@ -113,6 +113,7 @@ request adding CHANGELOG notes for breaking (!) changes and possibly other secti
loading the grants held by a principal, principal role or catalog role scans every grant record
in the realm, because the `grant_records` primary key continues with the securable columns after
`realm_id`. Existing CockroachDB deployments need a manual index creation โ see Upgrade notes.
+- Creating a namespace without an explicit location no longer fails with HTTP 400 when the catalog's `default-base-location` is nested under an allowed location rather than being equal to one. The derived location is now validated against the location it is derived from.
Review Comment:
Minor: The logic is good here, but feels hard to understand. I'd suggest to give an example, like `default-base-location` is `s3://b1/d1`, while allowed location is `s3://b1`.
> The derived location is now validated against the location it is derived from.
This is hard to understand as well :-), maybe we could make it more human readable.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Fix namespace creation rejecting its own default location [polaris]
Posted by "ayushtkn (via GitHub)" <gi...@apache.org>.
ayushtkn commented on code in PR #5357:
URL: https://github.com/apache/polaris/pull/5357#discussion_r3840412938
##########
runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/LocalIcebergCatalog.java:
##########
@@ -1457,24 +1457,19 @@ private void validateNamespaceLocation(
throw new IllegalArgumentException(
"Cannot create namespace without a parent storage configuration");
}
- List<StorageLocation> defaultLocations =
- parentEntity.getStorageConfigurationInfo().getAllowedLocations().stream()
- .filter(java.util.Objects::nonNull)
- .map(
- l ->
- StorageLocation.ensureTrailingSlash(
- StorageLocation.ensureTrailingSlash(l) + namespace.getName()))
- .map(StorageLocation::of)
- .toList();
- if (!defaultLocations.contains(namespaceLocation)) {
+ String parentLocation = resolveLocationForPath(diagnostics, List.of(parent));
+ StorageLocation defaultLocation =
+ StorageLocation.of(
+ StorageLocation.ensureTrailingSlash(
+ StorageLocation.ensureTrailingSlash(parentLocation) + namespace.getName()));
Review Comment:
added
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Fix namespace creation rejecting its own default location [polaris]
Posted by "Copilot (via GitHub)" <gi...@apache.org>.
Copilot commented on code in PR #5357:
URL: https://github.com/apache/polaris/pull/5357#discussion_r3840325179
##########
runtime/service/src/main/java/org/apache/polaris/service/catalog/iceberg/LocalIcebergCatalog.java:
##########
@@ -1457,24 +1457,19 @@ private void validateNamespaceLocation(
throw new IllegalArgumentException(
"Cannot create namespace without a parent storage configuration");
}
- List<StorageLocation> defaultLocations =
- parentEntity.getStorageConfigurationInfo().getAllowedLocations().stream()
- .filter(java.util.Objects::nonNull)
- .map(
- l ->
- StorageLocation.ensureTrailingSlash(
- StorageLocation.ensureTrailingSlash(l) + namespace.getName()))
- .map(StorageLocation::of)
- .toList();
- if (!defaultLocations.contains(namespaceLocation)) {
+ String parentLocation = resolveLocationForPath(diagnostics, List.of(parent));
+ StorageLocation defaultLocation =
+ StorageLocation.of(
+ StorageLocation.ensureTrailingSlash(
+ StorageLocation.ensureTrailingSlash(parentLocation) + namespace.getName()));
Review Comment:
Please check whether this user-visible fix needs a `CHANGELOG.md` entry under the Unreleased/Fixes section. With `ALLOW_NAMESPACE_CUSTOM_LOCATION=false`, plain `CREATE NAMESPACE` now succeeds when the catalog's `default-base-location` is nested under an allowed location, whereas it previously returned 400; no release-note or site-doc update accompanies that behavior change.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Fix namespace creation rejecting its own default location [polaris]
Posted by "flyrain (via GitHub)" <gi...@apache.org>.
flyrain commented on PR #5357:
URL: https://github.com/apache/polaris/pull/5357#issuecomment-5481307673
The PR looks good to me. The only minor comment is that creation still validates locations that Polaris derived itself, the option 1 in the following doesn't need a validation. I'm OK with a followup since this behavior is not introduced by this PR. Thanks @ayushtkn for working on it.
1. Flag false + no location โ derive and use the default location
2. Flag false + specified location equals default โ allow it; it is explicit but not custom
3. Flag false + specified location differs from default โ reject it as custom
4. Flag true + specified location โ allow custom location, subject to independent overlap checks
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
Re: [PR] Fix namespace creation rejecting its own default location [polaris]
Posted by "flyrain (via GitHub)" <gi...@apache.org>.
flyrain merged PR #5357:
URL: https://github.com/apache/polaris/pull/5357
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: issues-unsubscribe@polaris.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org