btlqql opened a new pull request, #4717:
URL: https://github.com/apache/rocketmq-dashboard/pull/4717
<!-- Base branch: `rocketmq-studio`, the RocketMQ Studio trunk. -->
### Which Issue(s) This PR Fixes
Related to #3163 (`Message Key queries cannot narrow by time range or tag`).
This PR covers the
server half of that issue:
> The backend also skips time-window validation whenever a key or message ID
is present. If a client
> sends an invalid key-query window, it is accepted rather than rejected
with the same validation
> used for topic queries.
It does not close the issue: the Message Explorer UI half (exposing the
tag/date-range controls in
key mode) is untouched.
### Brief Description
`MessageService.validateTopicQueryWindow` bails out as soon as a key or a
message id is present, so
a key query carrying an impossible window is forwarded to the provider
unchanged:
```java
// MessageService.java (before)
if (hasMessageId || hasKey) {
return; // no window validation for key queries
}
```
The providers do not agree on what to do with such a window, so the caller
cannot rely on a single
documented answer:
- `RocketMQMessageProvider.queryMessages` and
`TencentInstanceProvider.queryMessagesDetailed` both
reject a reversed window (`begin >= end`) with their own 400, but neither
checks the window for
negative timestamps - the raw value is passed to
`adminExt.queryMessage(topic, key, ...)` /
`DescribeMessageList`;
- `AliyunInstanceProvider.queryMessagesDetailed` checks neither and formats
both values into the
cloud `ListMessages` request.
A key query now validates a *supplied* window with the same 400 messages the
topic scan path already
returns. The window itself stays optional (a key query without timestamps
still delegates to the
provider's own default range), a single-sided window is still accepted, and
message-id lookups still
ignore the window because the providers treat them as point lookups.
No length bound is added: `docs/api-spec.md` ยง8.1 documents the seven-day
maximum as belonging to
topic scans that specify neither `msgId` nor `key`, so tightening key
queries would be a documented
contract change of its own.
### Related issue
Searched on 2026-09-21:
```
gh api
"search/issues?q=repo:apache/rocketmq-dashboard+is:pr+is:open+MessageService.java"
```
No open PR touches this validation. Four open PRs touch
`MessageService.java` for other reasons and
are not affected by this change: #4607 (direct-consume audit status), #4645
(truncation in the AI
message-query output), #4455 (cloud direct-consume support), #4424 / #4420
(queue filters and
timestamp-to-offset lookup). A fifth, #3164, implemented the same
server-side validation together
with a frontend change and was closed unmerged; this PR is the server half
only.
### How Did You Test This Change?
New tests in `MessageServiceTest`:
`keyQueryRejectsNegativeTimeWindowBeforeCallingProvider`,
`keyQueryRejectsInvalidTimeWindowBeforeCallingProvider` (reversed and
zero-width windows), plus
`keyQueryKeepsASingleSidedTimeWindow` and
`messageIdLookupStillIgnoresTheTimeWindow` as guards that
the window stays optional for key queries and unused for point lookups.
Before the fix (red) - both malformed windows were accepted and forwarded to
the provider:
```
$ cd server && mvn -B -ntp test -Dtest=MessageServiceTest
[ERROR] Tests run: 23, Failures: 2, Errors: 0, Skipped: 0, Time elapsed:
2.555 s <<< FAILURE! -- in
org.apache.rocketmq.studio.instance.message.MessageServiceTest
[ERROR]
org.apache.rocketmq.studio.instance.message.MessageServiceTest.keyQueryRejectsNegativeTimeWindowBeforeCallingProvider
-- Time elapsed: 0.136 s <<< FAILURE!
[ERROR]
org.apache.rocketmq.studio.instance.message.MessageServiceTest.keyQueryRejectsInvalidTimeWindowBeforeCallingProvider
-- Time elapsed: 0.008 s <<< FAILURE!
[ERROR]
MessageServiceTest.keyQueryRejectsInvalidTimeWindowBeforeCallingProvider:388
[ERROR]
MessageServiceTest.keyQueryRejectsNegativeTimeWindowBeforeCallingProvider:368
Expecting code to raise a throwable.
```
After the fix (green):
```
$ cd server && mvn -B -ntp test
-Dtest='MessageServiceTest,MessageControllerTest,QueryHistoryServiceTest'
[INFO] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0 -- in
org.apache.rocketmq.studio.instance.message.MessageControllerTest
[INFO] Tests run: 23, Failures: 0, Errors: 0, Skipped: 0 -- in
org.apache.rocketmq.studio.instance.message.MessageServiceTest
[INFO] Tests run: 12, Failures: 0, Errors: 0, Skipped: 0 -- in
org.apache.rocketmq.studio.instance.message.QueryHistoryServiceTest
[INFO] Tests run: 41, Failures: 0, Errors: 0, Skipped: 0
[INFO] BUILD SUCCESS
```
`mvn test` runs checkstyle in the `validate` phase: `You have 0 Checkstyle
violations.`
Note on the full suite: on a clean `rocketmq-studio` checkout `mvn -B -ntp
test` already reports
`Tests run: 3051, Failures: 6, Errors: 25, Skipped: 4`. The 11 red classes
are the MySQL 8 backed
Spring integration tests (`AuthServiceBootstrapIntegrationTest`,
`AuthServiceConcurrencyIntegrationTest`,
`AuthServiceSessionOverviewIntegrationTest`,
`HealthProbeIntegrationTest`, `QueryHistoryServiceIntegrationTest`,
`NativeAlertEvaluationTransactionTest`,
`NotificationOutboxMapperIntegrationTest`,
`RmqAlertStateMapperIntegrationTest`, `StudioApplicationTest`) plus the
external-CLI ones
(`CliAgentProviderTest`, `ClaudeCodeAgentProviderTest`). None of them are
touched by this change.
### Checklist
- [x] One coherent change; unrelated modifications are not bundled in
- [x] Commit subject follows Conventional Commits (`fix:`)
- [x] Tests added or updated for non-trivial changes, test methods named
`...Test`
- [x] New UI text has both Chinese and English entries under `web/src/i18n/`
(no UI text in this change)
- [x] Architecture constraints stay green (`mvn test` runs the ArchUnit
checks)
- [x] New source files carry the ASF license header (no new files)
- [x] Documentation touched where behaviour changed (no documented contract
change: the API spec only bounds topic scans)
--
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]
