JingsongLi commented on PR #10916: URL: https://github.com/apache/paimon/pull/10916#issuecomment-6556638779
The standalone `skipBytes` EOF/cursor defect is reproducible, and the one-line change follows the existing bulk-read EOF handling. I ran the 29 targeted cases in `AbstractPagedInputViewTest`, `BinaryRowSerializerLengthTest`, `BinaryRowSerializerPageSizeGuardTest`, and `BinaryRowSerializerShrinkTest` on JDK 8 with normal Maven `verify`; they pass, including Checkstyle, Spotless, Enforcer and RAT. This head's CI is green as well. The missing evidence is the end-to-end Paimon impact. The in-repository paged `skipBytes` consumer I could trace is `BinaryRowSerializer.skipRecordFromPages` (including the `InternalRowSerializer` delegation), used to skip a length-prefixed key in `BytesHashMap`. A valid serialized key does not request a skip beyond the available record area. The stream test directly combines `DataInputViewStream` and `RandomAccessInputView`, rather than exercising a production caller that reaches this EOF branch. I have not established a real table/engine workload whose result, recovery, or availability changes with this fix. Closing for now on contribution scope/end-to-end evidence, rather than an implementation defect. A real caller-level reproduction showing the affected workload and outcome would make this worth revisiting. -- 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]
