anuragmantri opened a new pull request, #3128: URL: https://github.com/apache/iceberg-rust/pull/3128
## Which issue does this PR close? - Closes https://github.com/apache/iceberg-rust/issues/3127 ## What changes are included in this PR? Resolves each manifest entry's `DataFile.sort_order_id` against the table's known sort orders and carries the result on a new `FileScanTask.sort_order field`. This follows the same PlanContext -> ManifestFileContext -> ManifestEntryContext plumbing already used for unified_partition_type. None means no sort order could be established, either because the file has no recorded `sort_order_id`, or because the id doesn't resolve against the table's known sort orders. This is groundwork for propagating sort-order awareness into the DataFusion integration (Part 2 of https://github.com/apache/iceberg-rust/issues/3126), which needs per-file sort-order data to decide whether a scan's output can be safely reported as sorted. ## Are these changes tested? Yes, a unit test covers all three resolution outcomes: - a sort_order_id that resolves - a file with no sort_order_id at all, and - a sort_order_id that doesn't resolve against the table's sort orders. The manifest-writing setup for this is factored into a new shared fixture helper alongside the existing `setup_*` variants. ## AI Disclosure I'm new to Rust and this codebase. I used Claude code (Opus 5) to assist me with the PR and the test coverage and I manually reviewed it. Please bear with me as I get familiar with Rust and the codebase. -- 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]
