unbridled-41 opened a new issue, #5892:
URL: https://github.com/apache/rocketmq-dashboard/issues/5892
### Studio Version
branch: `rocketmq-studio` @ `7e7aa344` (the revision verified; the branch is
based on it)
deployed as: not required to reproduce
### Runtime Environment
Reproduced with the backend unit tests (`cd server && mvn -o -B -ntp test
-Dtest='RocketMQMessageProviderTest'`); no MySQL and no cluster needed.
### Connected RocketMQ Cluster
Any Apache RocketMQ cluster whose key index holds messages older than an
hour.
### Describe the Bug
`RocketMQMessageProvider.queryMessages` computes one default window before
branching on the query mode:
```java
long end = endTime != null ? endTime : System.currentTimeMillis();
long begin = startTime != null ? startTime : end - ONE_HOUR_MILLIS;
if (begin >= end) { ... }
if (StringUtils.hasText(topic) && StringUtils.hasText(key)) {
return queryByKey(adminExt, topic, key, tag, begin, end); //
inherits the topic-scan default
}
```
A key lookup reads the broker's **key index** rather than scanning a topic,
and the API scope of that hour is the topic scan: "未指定 `msgId` 或 `key` 的 Topic
扫描默认查询最近 1 小时" (`docs/api-spec.md:1500`). The sibling lookup in the same class
defaults to three days (`UNIQUE_KEY_DEFAULT_WINDOW_MILLIS`, matching RocketMQ's
own `MQAdminImpl.queryMessageByUniqKey`), and the parent project searched from
0.
The console cannot widen the window either: key mode sends `{topic, key}`
with no times and the RangePicker is only rendered for `queryMode === 'topic'`
(`web/src/pages/instance/message.tsx`). So a message keyed more than an hour
ago is unreachable through the UI, the page reports "no results" for a message
that exists, and the AI message-query tool has the same default.
### Steps to Reproduce
1. Send a message with a business key to any topic, then wait more than an
hour (or backdate the store timestamp).
2. Studio → Message → query mode "Key", select the topic, enter the key.
3. The query returns no rows.
Measured window handed to the broker before the fix: `expected: 259200000L
(3 days) but was: 3600000L (1 hour)`.
### What Did You Expect to See?
A key lookup searches the window its documentation and its sibling
implementation imply - the key index window the console can actually reach
(three days), not the topic scan's hour.
### What Did You See Instead?
An empty result for a message that exists, with no way to widen the window
from the console.
### Evidence
-
`server/src/main/java/org/apache/rocketmq/studio/provider/apache/RocketMQMessageProvider.java:129-136`
(the shared default), `:283-285` (the unique-key default).
- `docs/api-spec.md:1500` (the hour is scoped to the topic scan).
- `web/src/pages/instance/message.tsx` (key mode sends no window; the
RangePicker is topic-only).
- `cd server && mvn -o -B -ntp test -Dtest='RocketMQMessageProviderTest'` -
the new case reports `expected: 259200000L but was: 3600000L` before the fix,
passes after.
### Impact
Triage by business key (order ids, payment ids) is the primary way operators
find a message that is not the newest one; for anything older than an hour the
page answers "no such message" and the query history records a successful query
with `resultCount=0`.
### Acceptance Criteria
- A key lookup with no explicit window searches the key-index default (three
days) while the topic scan keeps its documented hour, with a regression test
that pins the window handed to the broker, and the API spec states the key
default.
**Corresponding PR:** #5892
--
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]
