JingsongLi commented on PR #10911: URL: https://github.com/apache/paimon/pull/10911#issuecomment-6556739536
The low-level `DataInput.readLine` defect is real, and the implementation handles the final byte, CR/LF/CRLF, unsigned bytes and bounded slices consistently. I ran `DataInputDeserializerTest` and `DataOutputSerializerTest` on JDK 8 with normal Maven `verify`: all 22 cases pass, as do Checkstyle, Spotless, Enforcer and RAT. The PR's CI is green. However, I could not connect this change to an end-to-end Paimon workload. Repository-wide caller tracing found no production caller of `DataInputDeserializer.readLine()`. The text-format path uses `TextLineReader`/`StandardLineReader`, and `FileIO.readFileUtf8`, `IOUtils.readUTF8Fully`, version loading and benchmark line reads use other reader implementations. The new tests establish the standalone JDK contract, but do not demonstrate a table read/write, engine job or recovery path affected by this implementation. Closing for now because the current contribution lacks demonstrated end-to-end impact. This is not an implementation-correctness objection. Please provide an actual affected Paimon caller/workload and a regression at that boundary if there is one, and we can revisit the change. -- 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]
