dennishuo commented on issue #156: URL: https://github.com/apache/polaris/issues/156#issuecomment-2306423867
Thanks for the report! Indeed, it looks like the problem is that `registerTable` is the only thing in `BaseMetastoreCatalog` that tries to directly use the `ops.io()` immediately after building `ops = newTableOps(identifier)`. Whereas other flows either deal with an existing Table entity and by calling `current()` will trigger a `doRefresh()` which will properly initialize the FileIO with StorageConfiguration-based credentials, or else will go through a `doCommit` which also initializes the FileIO with the right credentials, this `registerTable` flow will revert to the catalog's "default" FileIO. The catalog's "default" FileIO is in some ways vestigial to make it easy for "Local FileSystem" based Java tests to work without having to mock out a fake credential-vending flow. We might want to refactor `BasePolarisCatalog` a bit to fast-fail if `BasePolarisTableOperations::io()` is ever used without being initialized with a `refreshIOWithCredentials` one way or another. This will also require some consideration for how the `validateNoLocationOverlap` enforcement works, and also `validateLocationForTableLike` so that it can't be abused to load metadata JSON files residing outside of the StorageConfiguration's ALLOWED_LOCATIONS. I'll try to draft a fix for this tomorrow. -- 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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
