Skip to content

Fix data loss when bucketized payload is an exact multiple of bucket size - #221

Open
LZD-PratyushBhatt wants to merge 1 commit into
devfrom
lzd/bucket-exact-multiple-fix
Open

Fix data loss when bucketized payload is an exact multiple of bucket size#221
LZD-PratyushBhatt wants to merge 1 commit into
devfrom
lzd/bucket-exact-multiple-fix

Conversation

@LZD-PratyushBhatt

Copy link
Copy Markdown
Collaborator

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

  • My PR addresses the following Helix issues and references them in the PR description:

(#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

  • Here are some details about my PR, including screenshots of any UI changes:

(Write a concise description including what, why, how)

Tests

  • The following tests are written for this issue:

(List the names of added unit/integration tests)

  • The following is the result of the "mvn test" command on the appropriate module:

(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)

  • My PR contains changes that break backward compatibility or previous assumptions for certain methods or API. They include:

(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)

  • In case of new functionality, my PR adds documentation in the following wiki page:

(Link the GitHub wiki you added)

Commits

  • My commits all reference appropriate Apache Helix GitHub issues in their subject lines. In addition, my commits follow the guidelines from "How to write a good git commit message":
    1. Subject is separated from body by a blank line
    2. Subject is limited to 50 characters (not including Jira issue reference)
    3. Subject does not end with a period
    4. Subject uses the imperative mood ("add", not "adding")
    5. Body wraps at 72 characters
    6. Body explains "what" and "why", not "how"

Code Quality

  • My diff has been formatted using helix-style.xml
    (helix-style-intellij.xml if IntelliJ IDE is used)

…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant