messere1 opened a new pull request, #424:
URL: https://github.com/apache/rocketmq-dashboard/pull/424
## What is the purpose of the change
Fix #380: Messages that have already been consumed are incorrectly displayed
as `NOT_CONSUME_YET` in the message track detail page.
## Root Cause
`MessageServiceImpl.messageTrackDetail()` delegates to
`DefaultMQAdminExtImpl.consumed()` which determines whether a message has been
consumed by comparing the consumer offset against the message's queue offset.
However, `consumed()` also requires an **exact broker-address match** between
`msg.getStoreHost()` and the broker's registered address:
```java
String addr =
NetworkUtil.convert2IpString(brokerData.getBrokerAddrs().get(MixAll.MASTER_ID));
if (NetworkUtil.socketAddress2String(msg.getStoreHost()).equals(addr)) {
if (next.getValue().getConsumerOffset() > msg.getQueueOffset()) {
return true;
}
}
```
When the broker registers with a hostname (e.g. `broker-a:10911`) and the
DNS resolution inside the dashboard JVM differs from the broker's environment,
`convert2IpString` produces a different IP string than
`socketAddress2String(msg.getStoreHost())`, causing the address comparison to
**silently fail**. As a result, `consumed()` returns `false` and the message is
reported as `NOT_CONSUME_YET` even though the consumer offset has already
advanced past the message.
A community member also confirmed in the issue: *"用控制台创建消费者组 消费状态就正常了"* —
suggesting the address-matching path is sensitive to how the consumer group and
broker are configured.
## Fix
Add a fallback verification in `MessageServiceImpl.messageTrackDetail()`:
when the underlying admin API returns `NOT_CONSUME_YET`, re-check the consumer
offset directly via `examineConsumeStats`, matching **only on topic + queueId +
offset** and skipping the fragile broker-address comparison. If the consumer
offset has advanced past the message's queue offset, the track type is
corrected to `CONSUMED`.
The fallback is:
- **Safe**: it only upgrades `NOT_CONSUME_YET` → `CONSUMED`, never the
reverse.
- **Resilient**: if `examineConsumeStats` throws or returns empty, the
original `NOT_CONSUME_YET` is preserved.
- **Minimal**: only affects the dashboard display layer; no change to the
core admin API.
## Brief changelog
- `MessageServiceImpl.java`: post-process `messageTrackDetail()` results —
re-verify `NOT_CONSUME_YET` tracks via `examineConsumeStats` without address
matching.
- `MessageServiceImplTest.java`: add 5 unit tests covering the new fallback
logic.
## Verifying this change
Unit tests added (`MessageServiceImplTest`):
1. `testMessageTrackDetail_NotConsumeYetCorrectedToConsumed` —
NOT_CONSUME_YET with consumerOffset > queueOffset → corrected to CONSUMED
2. `testMessageTrackDetail_NotConsumeYetRemainsWhenNotConsumed` —
NOT_CONSUME_YET with consumerOffset < queueOffset → remains NOT_CONSUME_YET
3. `testMessageTrackDetail_ConsumedTrackUnchanged` — CONSUMED track is not
re-verified
4. `testMessageTrackDetail_NotOnlineTrackUnchanged` — NOT_ONLINE track is
not re-verified
5. `testMessageTrackDetail_ExamineConsumeStatsThrowsException` — when
examineConsumeStats throws, original NOT_CONSUME_YET is preserved
All 20 tests in `MessageServiceImplTest` pass.
- [x] Make sure there is a Github issue filed for the change.
- [x] Format the pull request title like `[ISSUE #380] Fix NOT_CONSUME_YET
false positive in message track detail`.
- [x] Write a pull request description that is detailed enough.
- [x] Write necessary unit-test to verify your logic correction.
- [x] Run `mvn clean install -DskipITs` to make sure unit-test pass.
- [ ] If this contribution is large, please file an Apache Individual
Contributor License Agreement.
--
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]
