zjncs opened a new pull request, #4185:
URL: https://github.com/apache/rocketmq-dashboard/pull/4185
## Motivation
Message queries by key on Apache instances are silently capped at the
broker-side budget with no truncation signal:
- `RocketMQMessageProvider` never overrides `queryMessagesDetailed`, so the
interface default wraps every Apache query in
`MessageQueryResult.complete(...)` — `mayBeTruncated` is always `false`.
- `queryByKey` queries with `KEY_QUERY_MAX = 64`: a business key matching
more messages returns exactly 64 rows, `resultMayBeTruncated=false`, no warning
in the UI — every time, deterministically.
- The service-layer heuristic in `MessageService` (`topicQuery && size >=
200`) explicitly excludes key queries, so nothing else covers this.
- Tencent already reports this condition (#3048, merged) and Aliyun is being
fixed the same way (#4164, open). Apache is the default deployment, so the
widest audience is the one left with silently incomplete results.
Additionally, registered Apache instances dispatch through
`ApacheInstanceProvider` (via `InstanceProviderRegistry.byInstanceId`), which
also inherits the `complete(...)` default — so both dispatch paths need the
signal.
## Modification
- `RocketMQMessageProvider.queryMessagesDetailed` now carries the real
result. `queryByKey` sets `mayBeTruncated` when the merged result count reaches
`KEY_QUERY_MAX`. Note on exactness: `MQAdminImpl.queryMessage` fans the query
out to **every** route broker with a per-broker budget of `KEY_QUERY_MAX` and
merges the responses without a client-side cap, so an exact verdict cannot be
derived from the merged list — the conservative "budget reached" signal matches
the `mayBeTruncated` field semantics ("stopped because the result budget was
reached, not because the query was exhausted").
- The signal is computed **before** the client-side tag filter, which can
otherwise hide capped broker results behind an empty/short filtered list.
- `ApacheInstanceProvider.queryMessagesDetailed` delegates to the message
provider so registry-dispatched Apache instances reach the signal.
- Topic and msgId query behavior is unchanged (topic queries keep the
existing `>=200` service heuristic; msgId lookups return a single record).
## Verification
Fail-before (provider changes stashed, tests kept) — 3 failures:
```
[ERROR] Tests run: 52, Failures: 3
RocketMQMessageProviderTest.queryByKeyReportsTruncationWhenTheBrokerBudgetIsReached
RocketMQMessageProviderTest.queryByKeyKeepsTheTruncationSignalWhenTagFilteringDropsEveryRow
ApacheInstanceProviderTest.queryMessagesDetailedShouldDelegateToMessageProviderTest
```
Pass-after (fix applied):
```
RocketMQMessageProviderTest Tests run: 44, Failures: 0, Errors: 0
ApacheInstanceProviderTest Tests run: 8, Failures: 0, Errors: 0
MessageServiceTest Tests run: 17, Failures: 0, Errors: 0
```
New tests:
- `queryByKeyReportsTruncationWhenTheBrokerBudgetIsReached` — 64 merged
matches → `mayBeTruncated=true`, all 64 rows returned.
- `queryByKeyStaysCompleteBelowTheBrokerBudget` — 63 matches → complete.
- `queryByKeyKeepsTheTruncationSignalWhenTagFilteringDropsEveryRow` — 64 raw
matches, tag filter keeps none → still `mayBeTruncated=true` (signal survives
post-filtering).
- `queryMessagesDetailedShouldDelegateToMessageProviderTest` — registered
Apache instances reach the provider's signal instead of the `complete(...)`
default.
--
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]
