dhruvarya-db opened a new pull request, #3571: URL: https://github.com/apache/iceberg-rust/pull/3571
## Which issue does this PR close? None filed; the bug is small enough to describe here. ## What changes are included in this PR? `last-partition-id` is optional in format version 1 metadata. When it is missing, the v1 deserializer falls back to the highest partition **spec** id (`partition_specs.keys().max()`), which is usually 0, rather than the highest partition **field** id. A table with fields 1000 and 1001 therefore loads with `last_partition_id = 0`, and the next field added to a spec would get id 1 instead of 1002. That breaks the sequential field ids v1 requires. This defaults it the way Java's `TableMetadataParser` does: the highest field id across all specs, or 999 (`UNPARTITIONED_LAST_ASSIGNED_ID`) when no spec has fields, so the first field still gets 1000. ## Are these changes tested? Yes, unit tests in `table_metadata.rs`: - The v1 fixture test expected `last_partition_id: 0`, which recorded the bug. It now expects 1000. - The test that loads v1 metadata without `last-partition-id` now also checks that it comes out as 1001. - A new test covers an unpartitioned v1 table without `last-partition-id`, which gets 999. ## AI Disclosure Written with Claude Opus 5.5 and reviewed by me. The one thing worth checking is the 999 fallback for tables whose specs have no fields, which I took from Java's parser. -- 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]
