Pop revive service may process large revive offsets out of order

[yuluo-yx]

Description

PopReviveService builds its checkpoint list with a comparator that subtracts two long revive offsets and casts the difference to int. Offsets separated by more than Integer.MAX_VALUE can be reversed, causing mergeAndRevive to process checkpoints in the wrong order.

Expected behavior

Compare revive offsets with Long.compare so checkpoint order remains ascending across the full long range.

[RockteMQ-AI]

Issue Evaluation

Category: type/bug | Status: Confirmed

The issue is valid. The comparator in PopReviveService subtracts two long revive offsets and casts to int, which can reverse ordering when offsets differ by more than Integer.MAX_VALUE. This causes mergeAndRevive to process checkpoints out of order.

Root Cause: Comparator using (int)(a - b) pattern on long values instead of Long.compare(a, b).
Impact: Pop consumer — checkpoint revival order can be wrong, potentially causing message re-delivery or loss.
Severity: medium

Recommended fix: Replace the subtraction-based comparator with Long.compare(offset1, offset2).

An automated fix proposal can be generated. Reply /approve to proceed with PR generation.

---

Automated evaluation by RockteMQ-AI