qianye1001 opened a new issue, #10953: URL: https://github.com/apache/rocketmq/issues/10953
### Before Creating the Bug Report - [x] I found a bug, not just a question. - [x] I searched the GitHub issues and discussions and did not find a duplicate. - [x] I confirmed that this bug belongs to this repository. ### Runtime platform environment The issue is platform-independent. It was observed from the broker's `PeriodicMetricReader` thread while exporting consumer-lag metrics. ### RocketMQ version - Branch: `develop` - Commit: `293f5885719fc4aa3619446a1900f58ccfcfdd29` ### JDK Version The faulty offset calculation is independent of the JDK version. ### Describe the Bug When a filtered message count is estimated and the requested `from` offset is smaller than the ConsumeQueue minimum offset, `DefaultMessageStore.estimateMessageCount` shifts the range to the right while preserving its length. However, it does not clamp the shifted range to the current ConsumeQueue bounds. For example, a request for `[0, 200000)` with `minOffset = 190000` and `maxOffset = 200000` is changed to `[190000, 390000)`. The shifted upper bound exceeds the readable position of the ConsumeQueue. For the file-based ConsumeQueue, this can make `selectMappedBuffer` return `null`, leave `raw = 0` and `match = 0`, and report a filtered lag of zero. It also produces repeated warnings such as: ```text selectMappedBuffer request pos invalid, request pos: 2307920, size: 1416800, fileFromOffset: 0 ``` ### Steps to Reproduce 1. Use the file-based ConsumeQueue and enable accumulation estimation (the default). 2. Create a non-`*` TAG subscription so consumer lag uses a message filter. 3. Let old ConsumeQueue entries be removed so that the consumer offset is below the current minimum offset. 4. Estimate the count for `from = 0`, `to = 200000`, `minOffset = 190000`, and `maxOffset = 200000`. 5. Observe that the store asks the ConsumeQueue to estimate `[190000, 390000)` instead of a range within the current queue bounds. ### What Did You Expect to See? The requested interval should first be shifted to start at `minOffset` while preserving its length, and then both endpoints should be clamped to `[minOffset, maxOffset]`. In the example, the resulting range should be `[190000, 200000)`. If the shifted interval fits within the queue bounds, its original length should be preserved. If the available range is shorter, its upper end should be truncated at `maxOffset`. ### What Did You See Instead? The interval is shifted to the right without enforcing the current upper bound. The scan can exceed the ConsumeQueue readable range, emit `selectMappedBuffer request pos invalid` warnings, and incorrectly report zero filtered lag even when matching messages exist. ### Additional Context The problematic logic is in `DefaultMessageStore.estimateMessageCount`: ```java long diff = to - from; from = minOffset; to = from + diff; ``` The shifted range should be bounded by both `getMinOffsetInQueue()` and `getMaxOffsetInQueue()`. The addition also needs to avoid overflow for a very large requested upper bound. -- 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]
