[I] store/src/main/java/org/apache/rocketmq/store/pop/PopCheckPoint.java:215 - compareTo truncates 64-bit offsets and is inconsistent with equality [rocketmq]

["Metastarx (via GitHub)" <gi...@apache.org>]

Metastarx opened a new issue, #11360:
URL: https://github.com/apache/rocketmq/issues/11360

   PopCheckPoint.compareTo (store/src/main/java/org/apache/rocketmq/store/pop/PopCheckPoint.java:214-215) returns (int) (this.getStartOffset() - o.getStartOffset()). startOffset is a long queue offset, so the subtraction is 64-bit and the cast to int discards the high 32 bits; whenever two offsets differ by more than Integer.MAX_VALUE the sign of the result can be inverted, breaking the Comparable total-order contract (antisymmetry/transitivity). This is the same defect that was fixed for the mqadmin comparators (ConsumerProgressSubCommand/PrintMessageByQueueCommand/QueryMsgByUniqueKeySubCommand), which now use Long.compare.


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@rocketmq.apache.org.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org

Re: [I] store/src/main/java/org/apache/rocketmq/store/pop/PopCheckPoint.java:215 - compareTo truncates 64-bit offsets and is inconsistent with equality [rocketmq]

["RockteMQ-AI (via GitHub)" <gi...@apache.org>]

RockteMQ-AI commented on issue #11360:
URL: https://github.com/apache/rocketmq/issues/11360#issuecomment-6118113527

   **Issue Evaluation**
   
   Category: `type/bug` | Status: **Confirmed**
   
   The reported issue has been verified against the current codebase (`e1eb99c85296`).
   
   **Root Cause:** `PopCheckPoint.compareTo` (line ~215) casts the result of `long` subtraction to `int`, truncating the high 32 bits. When two start offsets differ by more than `Integer.MAX_VALUE`, the sign inverts, breaking the `Comparable` total-order contract.
   
   **Additional finding:** The same defect pattern also exists at `PopReviveService.java:725` (`(int)(o1.getReviveOffset() - o2.getReviveOffset())`), used in the pop revive comparator.
   
   **Impact:** Broker pop revive path — `TreeMap` keyed by `PopCheckPoint` in `PopReviveService` can misorder entries or fail lookups when offsets span a >2GiB range.
   
   **Fix:** Replace `(int)(a - b)` with `Long.compare(a, b)` at both locations. This matches the pattern already applied in `ConsumerProgressSubCommand`, `PrintMessageByQueueCommand`, and `QueryMsgByUniqueKeySubCommand`.
   
   **Related PR:** #11361 already addresses this issue.
   
   ---
   *Automated evaluation by github-manager-bot*


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: commits-unsubscribe@rocketmq.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org