[Bug] ProcessQueue may return a stale next offset for out-of-order messages

[yuluo-yx]

Before Creating the Bug Report

• I found a bug, not just a question.
• I searched open GitHub Issues and pull requests and found no duplicate.
• I confirmed that this bug belongs to Apache RocketMQ.

Runtime platform environment

macOS (Darwin), reproduced with an isolated local unit test.

RocketMQ version

Branch: develop
Git commit: fd0c959

JDK Version

Zulu OpenJDK 8 (8.94.0.17)

Describe the Bug

ProcessQueue.putMessage assigns queueOffsetMax from each newly inserted message. When a batch is not ordered by queue offset, a lower offset processed last overwrites the real maximum. After the queue is drained, removeMessage therefore returns a stale next offset.

Steps to Reproduce

1. Create a ProcessQueue.
2. Insert two messages in one batch with queue offsets 10 and 5, in that order.
3. Remove both messages.
4. Observe that the returned next offset is 6.

What Did You Expect to See?

The returned next offset should be 11, one greater than the highest offset ever inserted.

What Did You See Instead?

The returned next offset is based on the last iterated message rather than the maximum queue offset.

Additional Context

The issue is deterministic and is covered by ProcessQueueTest.

[RockteMQ-AI]

Issue Evaluation

Category: type/bug | Status: Confirmed

Root Cause: ProcessQueue may return a stale nextOffset when messages arrive out of order. The offset calculation does not account for gaps caused by out-of-order message delivery, leading to potential message skips or duplicates on rebalance.
Impact: Consumer correctness — during out-of-order delivery scenarios (e.g., network retries, broker failover), the consumer may report an incorrect offset, causing message loss or duplication after rebalance.
Severity: high

---

Automated evaluation by github-manager-bot