RockteMQ-AI commented on issue #10959: URL: https://github.com/apache/rocketmq/issues/10959#issuecomment-5326666527
**Issue Evaluation** Category: `bug` | Status: **Confirmed** The reported issue has been verified against the current codebase on the `develop` branch. **Root Cause:** `RocksDBConsumeQueue#iterateFrom(long startIndex)` only validates `startIndex >= 0 && startIndex < maxCqOffset` but never checks against `minOffsetInQueue`. This is inconsistent with the file-based `ConsumeQueue#getIndexBuffer` which returns `null` when `offset < getMinLogicOffset()`. **NPE Chain:** 1. `ScheduleMessageService#executeOnTimeUp` calls `cq.iterateFrom(this.offset)` 2. RocksDB returns a non-null `LargeRocksDBConsumeQueueIterator` (bypassing the null-check) 3. `hasNext()` returns `true` (only compares `currentIndex < totalCount`) 4. `next()` calls `consumeQueueStore.get(...)` → returns `null` for a purged offset 5. `cqUnit.getPos()` → **NullPointerException** **Impact:** Delayed message delivery stalls for the affected delay level. The timer task thread keeps hitting the same NPE on every retry since `this.offset` is never advanced before the exception. **Severity:** High **Recommended Fix:** Add a `minOffsetInQueue` check in both `iterateFrom(long)` and `iterateFrom(long, int)` overloads in `RocksDBConsumeQueue.java`, returning `null` when `startIndex < minCqOffset` — consistent with the file-based `ConsumeQueue` behavior. An automated fix proposal can be generated. Reply `/approve` to proceed with PR generation. --- *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: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
