[skyyyy955]

Purpose

When AbstractPagedInputView.skipBytes reaches EOF before satisfying the request, it counts the final page's remaining bytes but leaves the page cursor unchanged. A later read or skip can therefore consume those bytes again. Through DataInputViewStream, skipping Integer.MAX_VALUE + 1L on a seven-byte input can even return 10.

Advance the final page cursor before returning the partial count, following the existing EOF handling in the bulk-read method.

Tests

Validated on Windows 11 with JDK 8u451 and Maven 3.8.9, with normal Maven checks enabled:

• 18 new tests cover page boundaries, short final pages, repeated EOF operations, seeking back, stream adaptation, and propagation of non-EOF I/O errors. Eight fail before the fix; all pass afterward. JDK input streams provide independent controls.
• 11 existing tests in BinaryRowSerializerLengthTest, BinaryRowSerializerPageSizeGuardTest, and BinaryRowSerializerShrinkTest pass before and after the fix.
• Checkstyle, Spotless, Enforcer, and git diff --check pass.

Linux and the full table/engine suites were not run locally.

[JingsongLi]

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.