kevinjqliu commented on PR #2631: URL: https://github.com/apache/iceberg-rust/pull/2631#issuecomment-4702935419
I checked the Java implementation for comparison. It looks like Java is liberal at the raw positional-delete row layer: `PositionDelete` stores `pos` as a signed `long`, and the setter just assigns the value without validating that it is non-negative. The strict validation happens later when the rows are converted into a `PositionDeleteIndex`. `Deletes.toPositionIndexes` reads the position as `long` and calls `index.delete(position)`, which eventually reaches `RoaringPositionBitmap.set`, where Java validates that the position is `>= 0` and within the supported max range. So I think Rust should follow a similar split: * raw read / repair path: preserve the original signed `i64` value so malformed delete files can be inspected or repaired * scan/apply path: reject `pos < 0` before inserting into `DeleteVector` * avoid `pos as u64`; use `u64::try_from(pos)` or equivalent checked conversion The current PR fixes the wraparound bug, but because the validation is inside the parser that directly builds `DeleteVector`, it may make malformed delete files impossible to inspect through this path. -- 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]
