Avoid integer overflow in bucket count

[arkmish]

Issues

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

No linked issue. This overflow was identified while reviewing #221.

Description

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

The bucket-count calculation added two positive int values before dividing. For sufficiently
large configured bucket sizes or payloads, that addition wrapped to zero or a negative value,
causing writes or reads to use the wrong number of buckets.

For example, with a 100-byte compressed payload and bucketSize = Integer.MAX_VALUE, the expected
bucket count is 1. The existing int calculation evaluates
(100 + 2_147_483_647 - 1) / 2_147_483_647; its numerator wraps to -2_147_483_550, so Java
computes 0 buckets. The writer stores only metadata, and the reader reconstructs a zero-filled
buffer that fails GZIP decompression.

Promote the addition to long arithmetic in both the writer and reader before converting the
resulting bucket count back to int. There are no UI changes.

Tests

• The following tests are written for this issue:

• testWriteAndReadWhenBucketCountAdditionOverflows

• Local code review completed

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

mvn test -pl helix-core -am -Dtest=TestZkBucketDataAccessor -DfailIfNoTests=false

Tests run: 6, Failures: 0, Errors: 0, Skipped: 0

BUILD SUCCESS

Changes that Break Backward Compatibility (Optional)

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

None.

Documentation (Optional)

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

Not applicable.

Commits

• My commits follow the Helix commit-message guidelines. There is no linked Apache Helix issue for
  this narrowly scoped arithmetic fix.

Code Quality

• My diff has been formatted using helix-style.xml

🤖 Generated with GitHub Copilot CLI