HwangDongJun opened a new pull request, #12833:
URL: https://github.com/apache/gluten/pull/12833

   ## What changes are proposed in this pull request?
   
   `IcebergScanTransformer.getRootPathsInternal` was hardcoded to return 
`Seq.empty`, behind a `// TODO: get root paths from table.` comment 
(`gluten-iceberg/src/main/scala/org/apache/gluten/execution/IcebergScanTransformer.scala:196`).
   
   `BasicScanExecTransformer.doValidateInternal` passes this value as 
`rootPaths` into `VeloxBackend.validateScanExec`, whose `validateScheme()` only 
performs native filesystem scheme validation 
(`VeloxFileSystemValidationJniWrapper.allSupportedByRegisteredFileSystems`) 
when `filteredRootPaths.nonEmpty`. An empty `Seq` is therefore treated as 
"nothing to check", so scheme validation is silently skipped for every Iceberg 
scan regardless of the table's actual filesystem.
   
   As a result, Gluten does not correctly fall back to vanilla Spark for 
Iceberg tables backed by a filesystem scheme unsupported by the native build; 
any resulting failure instead surfaces later inside native code, in a much less 
clear form. See #12712.
   
   This PR returns the Iceberg table's base location, mirroring how DSv1/DSv2 
scans already expose their root paths via `FileIndex.rootPaths` 
(`BatchScanExecTransformer.getRootPathsInternal`). `table.location()` is the 
standard Iceberg API for a table's base location and is already used elsewhere 
in this codebase (e.g. `ContentFileUtil.java`).
   
   Fixes #12712.
   
   ## How was this patch tested?
   
   Added a regression test 
(`gluten-iceberg/src/test/scala/org/apache/gluten/execution/IcebergSuite.scala`)
 asserting `getRootPathsInternal` returns a non-empty root path for a plain 
Iceberg table, instead of the previous `Seq.empty`.
   
   Verified locally that `gluten-iceberg` (main + test sources) compiles 
cleanly against the change with `./build/mvn compile`/`test-compile -pl 
gluten-iceberg -am -Piceberg`, and that scalastyle reports 0 errors/warnings.
   
   ## Was this patch authored or co-authored using generative AI tooling?
   
   Generated-by: OpenCode claude-sonnet-5


-- 
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]


---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]

Reply via email to