RockteMQ-AI commented on issue #10955: URL: https://github.com/apache/rocketmq/issues/10955#issuecomment-5323468308
**Issue Evaluation** Category: `type/bug` | Status: **Confirmed** Thank you for the detailed analysis. The issue describes a plausible race condition in ordered consumption with `CONSUME_FROM_LAST_OFFSET`. **Root Cause Analysis:** The timeline you provided points to a race between offset computation and the first pull request: 1. **T=0.230s** — Consumer starts, `computePullFromWhere()` resolves `CONSUME_FROM_LAST_OFFSET` → `maxOffset = 9` 2. **T=0.398s** — A new message is written at offset 9 on queue 5 (bornTime) 3. **T=1.348s** — First actual `PullMessageRequest` is sent, but by this time `maxOffset` has advanced to 10, so the pull starts from offset 10 The message at offset 9 falls in the ~1.1s gap and is never fetched. This is consistent with the behavior where `computePullFromWhere()` is called during rebalance, but the actual pull request uses a freshly resolved `maxOffset` at pull time rather than the cached offset from rebalance. **Key Code Path:** In ordered consumption, `ConsumeMessageOrderlyService` relies on `ProcessQueue` locking and sequential pull. The issue likely stems from the interaction between: - `RebalanceService` computing the initial offset via `computePullFromWhere()` → `consumeFromWhere.computePullOffset()` - `PullAPIWrapper` or `PullMessageService` resolving the offset again at pull time If the offset is re-resolved against the broker's current `maxOffset` instead of using the cached value from rebalance, a message arriving in the gap will be skipped. **Related:** This pattern is similar to #2708 where offset resolution timing causes message skip in specific consumption modes. **Version Note:** You are running Server 4.9.7 + Client 4.7.1. The version mismatch between client and server may contribute to edge cases in offset negotiation. Consider testing with matched versions if possible. **Severity:** Medium — data loss in ordered consumption, but requires a specific timing window (message arriving between rebalance offset computation and first pull). **Suggested Investigation:** 1. Check if `computePullFromWhere()` result is cached and reused for the first pull, or if the offset is re-resolved 2. Verify whether `PullMessageService` uses the `ProcessQueue`'s cached `nextOffset` or calls `computePullFromWhere()` again 3. Check if this has been addressed in newer releases (5.x branch) --- *Automated evaluation by github-manager* -- 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]
