[fix] Avoid negative estimated entry count

[gaoran10]

Motivation

The estimated entry count may be a negative value in some cases, then the read operation will get an empty result.

Modifications

Add a negative check after the long value converts to an int value.

Does this pull request potentially affect one of the following parts:

If the box was checked, please highlight the changes

• Dependencies (add or upgrade a dependency)
• The public API
• The schema
• The default values of configurations
• The threading model
• The binary protocol
• The REST endpoints
• The admin CLI options
• The metrics
• Anything that affects deployment

Documentation

• doc
• doc-required
• doc-not-needed
• doc-complete

Matching PR in forked repository

PR in forked repository:

[lhotari]

The estimated entry count may be a negative value in some cases, then the read operation will get an empty result.

@gaoran10 Just wondering how it could the result could exceed Integer.MAX_VALUE so that the integer value becomes negative in the current logic. Is it the line result += remainEntriesOfLedger; in estimateEntryCountBySize method that causes it? Could we also improve the existing logic and add some test cases to reproduce and prevent such regressions?

[gaoran10]

Just wondering how it could the result could exceed Integer.MAX_VALUE so that the integer value becomes negative in the current logic. Is it the line result += remainEntriesOfLedger; in estimateEntryCountBySize method that causes it? Could we also improve the existing logic and add some test cases to reproduce and prevent such regressions?

You can try to use this newly added case in the test, if the bytesSize is a Long max value, the result may beyond the Integer max value.

var ml = (ManagedLedgerImpl) factory.open(mlName);
ml.addEntry(new byte[1000]);
int entryCount11 = ManagedCursorImpl.estimateEntryCountBySize(
        Long.MAX_VALUE, PositionFactory.create(ml.getCurrentLedger().getId(), 0), ml);

Wrong review

[BewareMyPower]

Add the same release/xxx labels since it's fixing the regression of #23931

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 74.20%. Comparing base (bbc6224) to head (475af0b).
Report is 952 commits behind head on master.

Additional details and impacted files

@@             Coverage Diff              @@
##             master   #24055      +/-   ##
============================================
+ Coverage     73.57%   74.20%   +0.62%     
+ Complexity    32624     2379   -30245     
============================================
  Files          1877     1861      -16     
  Lines        139502   144214    +4712     
  Branches      15299    16434    +1135     
============================================
+ Hits         102638   107008    +4370     
+ Misses        28908    28759     -149     
- Partials       7956     8447     +491     

Flag	Coverage Δ
inttests	26.65% <50.00%> (+2.07%)	⬆️
systests	23.09% <50.00%> (-1.24%)	⬇️
unittests	73.72% <100.00%> (+0.88%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Files with missing lines	Coverage Δ
...che/bookkeeper/mledger/impl/ManagedCursorImpl.java	79.62% <100.00%> (+0.32%)	⬆️

... and 1055 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[lhotari]

There was an additional regression caused by #23931 changes. I've created a PR #24089 to address it. Please review