[smengcl]

Generated-by: Claude Code (Opus 5.5)

What changes were proposed in this pull request?

ChunkInputStream.read(byte[], int, int) and read(ByteBuffer) can first copy bytes still buffered from the previous ReadChunk and then issue another ReadChunk for the rest. If that ReadChunk fails, the copied byte count is lost with the exception but the chunk position stays advanced. BlockInputStream.readWithStrategy then refreshes the pipeline and token and retries from the advanced position:

• byte[]: the ByteArrayReader offset never advanced, so the retry writes the following bytes over the start of the caller's buffer and reports success. The read silently returns wrong data and the stream ends up that many bytes ahead.
• ByteBuffer: the data lands in the right place but the count is short, so the read fails with "Inconsistent read" although the retry itself succeeded.

Triggers include a block token expiring on a long open stream (BLOCK_TOKEN_VERIFICATION_FAILED, which the client is designed to refresh and retry) or a transient datanode or network failure, combined with a sequential read that starts inside a buffered checksum range (any read size or seek offset not aligned to bytes per checksum).

Fix: when prepareRead throws after the call has already copied bytes, seek the chunk stream back by that many bytes (and reset the ByteBuffer position) before rethrowing, so a failed call has no effect and the retry resumes from where the call started. Successful reads and reads that fail before copying anything are unchanged. When retries are exhausted, the stream is now left at the start of the failed call instead of past the copied bytes.

Positioned reads and the streaming read path are not affected.

What is the link to the Apache JIRA

https://issues.apache.org/jira/browse/HDDS-17000

How was this patch tested?

Added retriedReadReturnsContiguousData and failedReadLeavesPositionUnchanged to TestBlockInputStream, using a real ChunkInputStream with ReadChunk stubbed to fail with BLOCK_TOKEN_VERIFICATION_FAILED, for both byte[] and ByteBuffer, after an unaligned and an aligned first read. Without the fix, the four unaligned/exhausted cases fail (wrong bytes, "Inconsistent read", wrong position); with the fix all pass.

Also verified locally: the reproduction attached to the JIRA shows the defect on master and no longer does with the fix; hdds-client and ozone-client unit tests, TestChunkInputStream and TestKeyInputStream pass; checkstyle is clean.

🤖 Generated with Claude Code

[Copilot]

Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.