zmuxuny opened a new issue, #6177: URL: https://github.com/apache/rocketmq-dashboard/issues/6177
### Before Creating the Bug Report - [x] I have searched the [open issues](https://github.com/apache/rocketmq-dashboard/issues) of this repository and believe that this is not a duplicate. - [x] This is a defect in RocketMQ Studio, not a usage question and not a defect in another Apache RocketMQ repository. - [x] I can reproduce this on the current `master` branch, or I have stated the exact version I am running below. ### Studio Version rocketmq-studio@5e4c39b0, inspected 2026-10-10. ### Runtime Environment Source inspection of the Apache RocketMQ provider and official RocketMQ 5.5 pull-status protocol. The reproduction below specifies controlled responses for the existing mocked provider fixtures; the new regression has not yet been executed. No production incident is claimed. ### Connected RocketMQ Cluster Apache RocketMQ provider. No live cluster or live broker mutation is used or claimed. ### Build Toolchain _No response_ ### Describe the Bug The topic query and dead-letter scan loops treat PullStatus.NO_MATCHED_MSG as the end of a queue. This status can instead mean the broker skipped a range and supplied a later nextBeginOffset to continue reading. Later readable messages are then omitted from query results or dead-letter replay. RocketMQ 5.5 PullMessageProcessor maps store statuses MESSAGE_WAS_REMOVING and NO_MATCHED_MESSAGE to PULL_RETRY_IMMEDIATELY, which the client maps to NO_MATCHED_MSG. Therefore the wildcard * pull does not make this status impossible: it can occur while traversing removed message data as well as non-matching data. ### Steps to Reproduce Use controlled pull responses within the existing provider test fixtures: 1. Queue starts at offset 10, with the requested range ending at 50. 2. Pull at 10 returns NO_MATCHED_MSG, nextBeginOffset=20. 3. Pull at 20 would return FOUND, containing one in-window message, and nextBeginOffset=40. 4. Pull at 40 returns NO_NEW_MSG. This report is based on the current loops and controlled response sequencing, not a captured production incident. Regression implementation will use the existing mocked provider test harness; no dependency, API or live-cluster change is needed. ### What Did You Expect to See? For NO_MATCHED_MSG, continue from an advancing nextBeginOffset while preserving non-advancing-offset termination, the topic pull-attempt budget, and each scan's end-offset/result limits. NO_NEW_MSG remains a terminal condition. ### What Did You See Instead? RocketMQMessageProvider.queryByTopic breaks on the first response and returns no message instead of visiting offset 20. RocketMQDLQProvider.scanDeadLetters similarly breaks at its non-FOUND guard (around line 500); a replay finds zero messages / NOT_FOUND instead of matching and resending the message at offset 20. ### Additional Context ### Protocol sources - https://github.com/apache/rocketmq/blob/rocketmq-all-5.5.0/broker/src/main/java/org/apache/rocketmq/broker/processor/PullMessageProcessor.java - https://github.com/apache/rocketmq/blob/rocketmq-all-5.5.0/client/src/main/java/org/apache/rocketmq/client/impl/MQClientAPIImpl.java ### Duplicate check and boundaries Open #5523 covers topic scan completeness/truncation reporting; its patch does not handle NO_MATCHED_MSG. Open #4592 counts abandoned DLQ queues after stalls or repeated illegal offsets; it does not continue skipped ranges. Historical #4095 / #4424 concern a separate native queue-filter preview feature. This fix will group the topic and DLQ instances of the same incorrect pull-status interpretation. It will not duplicate #5523's truncation-result redesign or #4592's abandoned-queue accounting. ### Acceptance criteria - Topic query reaches and returns the later readable message after an unmatched batch. - DLQ scan/replay reaches the later matching dead letter. - Preserve the topic pull-attempt budget and each scan's end-offset/result limits for consecutive unmatched batches. - Non-advancing offsets cannot loop indefinitely. - NO_NEW_MSG still ends the scan without an extra pull. AI assistance was used to inspect provider loops and the official RocketMQ protocol mapping. ### Are You Willing to Submit a Pull Request? - [x] Yes, I am willing to submit a pull request. -- 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]
