Aias00 opened a new issue, #901: URL: https://github.com/apache/rocketmq-dashboard/issues/901
### What happened? `RocketMQMessageProvider.queryByTopic` calls `DefaultMQPullConsumer.fetchSubscribeMessageQueues(topic)` and immediately iterates the returned set. If the RocketMQ client returns `null` for the queue set, the enhanced for-loop throws a `NullPointerException`. The catch block then logs the failure and returns an empty list. That makes a provider/runtime failure look the same as a legitimate "no messages found" result in the Studio message query flow. ### Location - `server/src/main/java/org/apache/rocketmq/studio/rocketmq/RocketMQMessageProvider.java` ### Expected behavior The provider should handle a null queue set explicitly and return an empty result without relying on an exception path. This keeps the Topic + time range query path deterministic and avoids noisy/ambiguous failures. ### Scope This is in the RocketMQ Studio BASE-01 message query baseline: the migrated message query capability should not degrade when the RocketMQ admin/pull client returns incomplete metadata. ### Suggested fix Guard the queue set before iterating it and add a unit test for the null return case. -- 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]
