zmuxuny opened a new issue, #4524:
URL: https://github.com/apache/rocketmq-dashboard/issues/4524
### Before Creating the Bug Report
- [x] I searched open/closed issues and PRs for message-id lookup failures,
`viewMessage`, empty results, and msgId diagnostics.
- [x] I reproduced the behavior on current `master`
(`987b748e8f4f421c5cd3c4c4e51a064cc7e59f18`).
### Problem
The Apache message query path turns real message-ID lookup failures into a
confirmed empty result.
`RocketMQMessageProvider.queryByMsgId` catches every exception from
`DefaultMQAdminExt.viewMessage(topic, msgId)`, logs it, then tries the
decoded-offset fallback. `viewMessageByOffsetId` also catches every exception
and returns `null`. If neither path returns a message, the provider returns an
empty list.
For a non-offset/unique message id, the fallback cannot decode the id at
all. A NameServer/Broker/RPC failure from the primary lookup is therefore
indistinguishable from "message not found". For an offset msgId, a primary RPC
failure followed by a direct Broker lookup failure has the same false-empty
outcome.
### Impact
Message-ID lookup is an incident-diagnostic path. Returning `0 messages`
after a transport/provider failure can make an operator conclude that a message
does not exist when Studio actually failed to query it.
Other message query paths already distinguish absence from operational
failure: key and unique-key queries return empty only for known no-message
response codes and surface unexpected failures as HTTP-style 502 errors.
### Expected Behavior
- Known no-message / query-not-found outcomes remain valid empty results.
- Existing broker-topology rejection for unsafe offset ids remains
fail-closed and does not trigger an outbound lookup.
- If the primary lookup fails but the validated decoded-offset fallback
succeeds, preserve the successful fallback behavior.
- If an actual lookup is attempted and all applicable lookup paths fail
operationally, return a 502-style `BusinessException` instead of a confirmed
empty result.
### Red Reproduction
On unmodified `master`, I added one regression where `viewMessage("TopicA",
"uniq-key-failure")` throws `IllegalStateException("nameserver unavailable")`
and require the provider to surface 502.
`RocketMQMessageProviderTest`: **55 tests, exactly 1 failure**. The new test
fails with `Expecting code to raise a throwable`, while the provider logs the
failure and returns an empty list.
### Proposed Scope
Keep the public API shape unchanged. Classify known not-found response codes
separately from operational failures, preserve the existing offset-id fallback,
and add focused tests for unique-key failure, offset fallback failure/success,
and genuine not-found behavior.
AI-assisted source audit and regression authoring; the fail-before test was
executed locally with Java 21.
--
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]
