thswlsqls opened a new issue, #17054: URL: https://github.com/apache/iceberg/issues/17054
**Apache Iceberg version** main @ 035fc1e40 **Query engine** N/A — engine-agnostic, affects the Dell ECS `FileIO` implementation **Please describe the bug** `EcsFileIO` does not override `FileIO#newInputFile(String path, long length)` (`dell/src/main/java/org/apache/iceberg/dell/ecs/EcsFileIO.java` line 56-59), so every call falls back to the `api/` default that discards the known length (`FileIO.java` line 46-48). `EcsInputFile#getLength()` (`EcsInputFile.java` line 54-57) has no cached length field, so it issues a fresh `getObjectMetadata()` HEAD request to ECS every time it is called, even though callers such as `newInputFile(DataFile)`/`newInputFile(DeleteFile)`/`newInputFile(ManifestFile)` already know the file size. `S3FileIO`, `GCSFileIO`, `ADLSFileIO`, and `OSSFileIO` all override `newInputFile(String, long)` and cache the length in their respective `InputFile` implementations (e.g. `aliyun/src/main/java/org/apache/iceberg/aliyun/oss/OSSInputFile.java` line 30, 47-53). Dell is the only cloud `FileIO` module missing this, resulting in avoidable HEAD requests during scan planning. **Steps to reproduce** 1. Call `EcsFileIO#newInputFile(path, knownLength)` with a length obtained from a `DataFile`/`ManifestFile`. 2. Call `getLength()` on the returned `InputFile`. 3. Expected: the known length is returned without a network call. Actual: `getObjectMetadata()` is called against ECS regardless. **Additional context** N/A — covered above. -- 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]
