hutiefang76 opened a new issue, #4407: URL: https://github.com/apache/amoro/issues/4407
### What happened? `HudiTableDescriptor.getSnapshots` casts the long total file size to int before assigning it to a long field. A 3 GiB snapshot therefore becomes -1073741824 bytes instead of 3221225472 bytes. Larger values can also wrap to a smaller positive size. ### Affects Versions Reproduced on master at `9442f8c`. Released versions have not been checked. ### What table formats are you seeing the problem on? Hudi ### What engines are you seeing the problem on? AMS ### How to reproduce 1. Provide a `HudiSnapshot` with total file size `3221225472L` (3 GiB) through `HudiTable.getSnapshotList`. 2. Call `HudiTableDescriptor.getSnapshots` and read `getOriginalFileSize()` on the returned snapshot. 3. The result is `-1073741824L`; expected `3221225472L`. The regression test uses a real Hudi snapshot and descriptor, with the table snapshot lookup mocked so it does not require Hudi storage. ### Relevant log output For a 3 GiB snapshot: `expected: <3221225472> but was: <-1073741824>`. ### Anything else Proposed fix: Remove the narrowing int cast. Add size-boundary regressions, including Integer.MAX_VALUE, 2 GiB, 3 GiB and 5 GiB, plus field-mapping, operation-filtering and empty-list coverage. Code was assisted by DeepSeek v4 Flash via Reasonix 1.39.4; submission text was assisted by Codex. The patch and local test results were reviewed. ### Are you willing to submit a PR? - [x] Yes I am willing to submit a PR! ### Code of Conduct - [x] I agree to follow this project's Code of Conduct -- 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]
