3219378872 opened a new issue, #5103: URL: https://github.com/apache/rocketmq-dashboard/issues/5103
### Describe the bug The Apache DLQ scanner can stop after its first pull batch when more than 32 messages share the inclusive end timestamp. It returns an apparently complete result while silently omitting the remaining matching messages. `scanDeadLetters` obtains `maxOffset` using `consumer.searchOffset(queue, end)`. That API searches the **lower** timestamp boundary, so it identifies the first message stored at `end`. After one 32-message pull advances beyond that offset, `offset <= maxOffset` ends the scan even if more messages have exactly the same timestamp. The per-message filter correctly treats the end time as inclusive, but the offset window does not cover that full inclusive interval. ### Reproduction Verified on `rocketmq-studio` commit `a562601d0971001c1cd3b888a9f2664b6ef77811` with the actual `RocketMQDLQProvider.exportMessages` and RocketMQ client 5.5.0 against an isolated real NameServer/Broker: 1. Create a one-queue `%DLQ%` topic in the disposable Broker. 2. Send 80 messages in one batch through `DefaultMQProducer`. Pull them directly to verify that all 80 exist and share the same broker-assigned store timestamp `T`. 3. Send a later message outside the intended window. 4. Call `exportMessages(instance, group, T - 1, T, 1000)`. Actual result: ```text LIVE_DLQ expected=80 actual=32 failedQueues=0 truncated=false lowerEnd=0 exclusiveEnd=80 ``` The test supplies the isolated pull consumer through the instance resolver; offset searches, message pulls and export mapping all execute normally against the real Broker. Neither message timestamps nor offset/pull responses are mocked. This is provider integration evidence, not a claim of a complete Studio deployment. ### Expected behavior Return all 80 matching messages, without including the later message. The existing inclusive time filter should be backed by an exclusive offset limit obtained from `end + 1`, with `Long.MAX_VALUE` handled without overflow. The same shared scanner also serves other DLQ operations. ### Related work checked All-state DLQ boundary/time/scan searches found no matching fix. #4592 concerns abandoned-queue failure reporting, #4927 concerns the scan-cap disclosure, and #4929 concerns the drawer's time range. They do not fix this timestamp-boundary undercount. The ordinary topic-message scanner already uses an inclusive-time/exclusive-offset window. -- 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]
