Fix data loss when bucketized payload is an exact multiple of bucket size - #221
Open
LZD-PratyushBhatt wants to merge 1 commit into
Open
Fix data loss when bucketized payload is an exact multiple of bucket size#221LZD-PratyushBhatt wants to merge 1 commit into
LZD-PratyushBhatt wants to merge 1 commit into
Conversation
…size The bucketized writer sliced the final bucket using "compressedRecord.length % _bucketSize". When the GZIP compressed payload length happens to be an exact multiple of the bucket size that remainder is zero, so the last bucket was written empty and its bytes were dropped. The reader then reassembled a truncated buffer and every subsequent read of that path failed with "Failed to decompress path". The record was effectively unrecoverable until the next write landed on a non-multiple length. The reader had the mirror image of the same bug in its final-bucket arraycopy, and it also advanced its copy pointer only on the non-final branch, so the final chunk was copied to the wrong offset. Slice and copy to the end of the payload instead of relying on the remainder, which is correct for both the exact-multiple and the partial final bucket cases. The reader additionally computed the bucket count from its own configured _bucketSize rather than the BUCKET_SIZE the writer recorded in the metadata ZNode. An accessor constructed with a different bucket size than the writer therefore looked for the wrong number of buckets and failed the same way. Use the persisted bucket size, which is the authoritative value, and fail with an explicit message if a bucket is missing or short rather than throwing an opaque ArrayIndexOutOfBoundsException. Both cases are covered by new tests that fail without this fix. Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
LZD-PratyushBhatt
requested review from
arkmish,
laxman-ch,
ngngwr and
thestreak101
as code owners
August 9, 2026 01:08
4 tasks
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The bucketized writer sliced the final bucket using "compressedRecord.length % _bucketSize". When the GZIP compressed payload length happens to be an exact multiple of the bucket size that remainder is zero, so the last bucket was written empty and its bytes were dropped. The reader then reassembled a truncated buffer and every subsequent read of that path failed with "Failed to decompress path". The record was effectively unrecoverable until the next write landed on a non-multiple length.
The reader had the mirror image of the same bug in its final-bucket arraycopy, and it also advanced its copy pointer only on the non-final branch, so the final chunk was copied to the wrong offset.
Slice and copy to the end of the payload instead of relying on the remainder, which is correct for both the exact-multiple and the partial final bucket cases.
The reader additionally computed the bucket count from its own configured _bucketSize rather than the BUCKET_SIZE the writer recorded in the metadata ZNode. An accessor constructed with a different bucket size than the writer therefore looked for the wrong number of buckets and failed the same way. Use the persisted bucket size, which is the authoritative value, and fail with an explicit message if a bucket is missing or short rather than throwing an opaque ArrayIndexOutOfBoundsException.
Both cases are covered by new tests that fail without this fix.
Issues
(#200 - Link your issue number here: You can write "Fixes #XXX". Please use the proper keyword so that the issue gets closed automatically. See https://docs.github.com/en/github/managing-your-work-on-github/linking-a-pull-request-to-an-issue
Any of the following keywords can be used: close, closes, closed, fix, fixes, fixed, resolve, resolves, resolved)
Description
(Write a concise description including what, why, how)
Tests
(List the names of added unit/integration tests)
(If CI test fails due to known issue, please specify the issue and test PR locally. Then copy & paste the result of "mvn test" to here.)
Changes that Break Backward Compatibility (Optional)
(Consider including all behavior changes for public methods or API. Also include these changes in merge description so that other developers are aware of these changes. This allows them to make relevant code changes in feature branches accounting for the new method/API behavior.)
Documentation (Optional)
(Link the GitHub wiki you added)
Commits
Code Quality
(helix-style-intellij.xml if IntelliJ IDE is used)