feat(io): add ResolvingFileIO to resolve FileIO by location scheme and forward vended credentials - #828
Conversation
|
Could we add an end-to-end test using the actual Arrow FileIO implementations? The current tests use mocks and don’t cover the full |
There was a problem hiding this comment.
Pull request overview
This PR introduces a core ResolvingFileIO that selects the concrete FileIO implementation based on each file path’s URI scheme (instead of inferring from warehouse), and updates the REST catalog defaults and S3 credential handling to match Iceberg Java semantics for vended credentials.
Changes:
- Add
ResolvingFileIO(core) with per-scheme resolution, lazy loading viaFileIORegistry, caching, and forwarding of vended storage credentials. - Change REST catalog
MakeCatalogFileIOdefault toresolving-file-iowhenio-implis unset; remove warehouse-based auto-detection and compatibility checks. - Update
ArrowS3FileIO::SetStorageCredentialsto skip (not reject) non-S3 credential prefixes and warn when none are S3-compatible; add/adjust tests accordingly.
Reviewed changes
Copilot reviewed 14 out of 14 changed files in this pull request and generated no comments.
Show a summary per file
| File | Description |
|---|---|
| src/iceberg/test/rest_file_io_test.cc | Updates REST FileIO tests for resolving default and logical-warehouse credential binding regression coverage. |
| src/iceberg/test/resolving_file_io_test.cc | Adds unit tests for scheme resolution, routing/caching behavior, and credential forwarding semantics. |
| src/iceberg/test/meson.build | Adds resolving_file_io_test.cc to Meson test sources. |
| src/iceberg/test/CMakeLists.txt | Adds resolving_file_io_test.cc to CMake test sources. |
| src/iceberg/test/arrow_s3_file_io_test.cc | Updates S3 FileIO credential-prefix behavior tests (skip non-S3; accept no-S3 case). |
| src/iceberg/resolving_file_io.h | Declares new ResolvingFileIO API and caching/credential-forwarding behavior. |
| src/iceberg/resolving_file_io.cc | Implements per-scheme resolution, lazy registry loading, caching, and credential forwarding. |
| src/iceberg/meson.build | Adds resolving_file_io.cc to core build sources and installs the new header. |
| src/iceberg/file_io_registry.h | Introduces the kResolvingFileIO registry name constant. |
| src/iceberg/file_io_registry.cc | Pre-registers resolving-file-io in the registry state constructor. |
| src/iceberg/CMakeLists.txt | Adds resolving_file_io.cc to core CMake sources. |
| src/iceberg/catalog/rest/rest_file_io.h | Removes builtin-detection declarations; documents resolving default behavior. |
| src/iceberg/catalog/rest/rest_file_io.cc | Defaults to resolving-file-io when io-impl is unset; simplifies table FileIO creation flow. |
| src/iceberg/arrow/s3/arrow_s3_file_io.cc | Skips non-S3 credential prefixes and logs a warning when all are skipped. |
| } | ||
| // S3-compatible schemes served by the S3 FileIO (Java: SCHEME_TO_FILE_IO). | ||
| // Keep in sync with CanonicalizeS3Scheme in arrow_s3_file_io.cc. | ||
| if (scheme == "s3" || scheme == "s3a" || scheme == "s3n" || scheme == "oss") { |
There was a problem hiding this comment.
Please either remove oss from this mapping or make ArrowS3FileIO accept and canonicalize oss:// credentials. REST credentials are scoped by storage-location prefix, but the S3 delegate currently drops oss:// credentials and falls back to its defaults. A catalog that vends only oss://bucket/table credentials will therefore fail at I/O time. Java avoids this mismatch by not mapping oss to S3FileIO.
There was a problem hiding this comment.
@wgtmac Fixed via your second option: ArrowS3FileIO now accepts and canonicalizes oss:// credential prefixes. Removing oss from the mapping isn't viable here — unlike Java, arrow-fs-s3 is the only C++ impl that can serve oss://, so that would turn those locations into NotSupported.
| Status ResolvingFileIO::SetStorageCredentials( | ||
| const std::vector<StorageCredential>& storage_credentials) { | ||
| std::lock_guard lock(mutex_); | ||
| storage_credentials_ = storage_credentials; |
There was a problem hiding this comment.
Please do not update storage_credentials_ until the cached delegates have accepted the new credentials. If one delegate rejects the update, this method returns an error while credentials() reports the new values and the cached delegate keeps using the old ones; later cache hits never retry. Invalidating and rebuilding delegates on credential changes may be simpler than rolling back partial updates.
There was a problem hiding this comment.
@wgtmac Went with your simpler suggestion: SetStorageCredentials now invalidates the delegate cache and rebuilds lazily, so there's no window where a rejecting delegate leaves credentials() and the live delegates disagreeing. The test asserts the rebuild (factory invoked again, new delegate gets the new creds).
| ~ResolvingFileIO() override; | ||
|
|
||
| /// \brief The FileIORegistry name of the implementation serving `location`. | ||
| static Result<std::string_view> ResolveFileIOName(std::string_view location); |
There was a problem hiding this comment.
Can this be private or internal? The resolver and its tests are the only callers, while exposing registry implementation names from an installed header makes the current scheme mapping part of the public API. Java keeps the equivalent implFromLocation package-private.
There was a problem hiding this comment.
@wgtmac Done — now a free function in resolving_file_io_internal.h (not installed), so the scheme mapping is no longer public API. It keeps ICEBERG_EXPORT only so tests link in shared builds, as arrow/arrow_io_internal.h does.
| ASSERT_THAT(result, IsOk()); | ||
|
|
||
| // Reaching a data file routes to the S3 FileIO with the full credential list. | ||
| (void)result.value()->NewInputFile("oss://bucket/db/table/data/file.parquet"); |
There was a problem hiding this comment.
Could we cover this path with the real registered Arrow S3 FileIO? The mock only proves that the full credential list reaches the delegate; it cannot catch that production ArrowS3FileIO drops the oss:// credential before opening this oss:// location. A focused REST -> ResolvingFileIO -> FileIORegistry -> ArrowS3FileIO test would catch this regression.
There was a problem hiding this comment.
@wgtmac Added test/rest_arrow_file_io_test.cc, covering the chain against the real registered Arrow implementations on both legs: a local write/read round-trip with real bytes, and an oss:// case where any break in routing/forwarding/prefix handling shows up as the warning, which the test asserts is absent. Also fixed add_rest_iceberg_test, which declared USE_BUNDLE but never used it, so REST tests couldn't link the bundle.
@MisterRaindrop Done in |
…d forward vended credentials
0c9a813 to
ae4f1ac
Compare
Follow-up to #719: replaces the temporary warehouse-based FileIO detection
with a scheme-based
ResolvingFileIO, mirroring Java.Why
The FileIO impl was picked from
DetectBuiltinFileIO(warehouse), so anynon-
s3://warehouse resolved toarrow-fs-localand binding vendedcredentials failed with
Configured FileIO does not support vended storage credentials. Credential-vending catalogs typically use a logical warehouseidentifier (bucket ARN / catalog name), not a storage URI, so the feature
only worked when
warehousewas literallys3://….What
ResolvingFileIO(core) — picks the impl per file-path scheme(
s3/s3a/s3n/oss→arrow-fs-s3;file/no scheme → local; elseNotSupported), lazily loaded viaFileIORegistryand cached; forwardsthe full credential list to impls that support it (Java
ResolvingFileIOsemantics). Registered asresolving-file-io.MakeCatalogFileIOdefaults toresolving-file-iowhen
io-implis unset (JavaDEFAULT_FILE_IO_IMPLlikewise); thewarehouse detection and the
io-impl-vs-warehouse check are removed.Explicit
io-implis honored as before.ArrowS3FileIO—SetStorageCredentialsskips non-S3 credentialprefixes instead of rejecting the set (Java
S3FileIOfilters by"s3");servers may vend credentials for several storage systems at once.