apache / apache/rocketmq-dashboard

[Studio][Performance] Bound and page AI message query results

Open
#4,147 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
Java
Stars
1.4k
Forks
683
Avg merge
2d 12h
Merged PRs (30d)
62

Description

## Problem

The read-only AI/MCP tool `rmq.message.query` delegates to the non-paged `MessageService.queryMessages` path and projects every returned message with its full body. A bounded provider scan can still return many messages, and message bodies may be large, so one tool call can consume a disproportionate amount of the MCP response and LLM context.

The standard REST message endpoint already exposes `queryMessagesPage`, including `total`, `page`, `size`, and `resultMayBeTruncated`. The Topic and Consumer Group AI tools already use a paged `{items, total, page, size}` envelope, but the message tool still returns a raw array.

## Expected behavior

- Add optional `page` and `pageSize` inputs to `rmq.message.query`.
- Default to page 1 with 20 items and cap `pageSize` at 100.
- Delegate to the existing `MessageService.queryMessagesPage` path.
- Return `{items, total, page, size, resultMayBeTruncated}` so callers can distinguish a complete page from a provider-capped result.
- Add optional `includeBody`, defaulting to `false`.
- Omit `body`, `bodyEncoding`, and `bodyTruncated` unless `includeBody=true`; retain message identity, routing, timestamps, hosts, and size.
- Preserve the existing query filters and L1 read-only permission classification.

## Compatibility

The paged envelope intentionally aligns this tool with `rmq.topic.list` and `rmq.group.list`. The canonical output schema and handler must change together so schema-driven MCP/CLI clients can render the new contract.

## Acceptance criteria

- Catalog validation covers the new inputs and paged output metadata.
- Handler tests prove default paging, custom paging, body omission, explicit body inclusion, and truncation metadata.
- Invalid paging values continue to be rejected through the catalog/service validation path.
- No provider-specific query implementation changes are included.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start at the rmq.message.query catalog entry and handler, then trace the existing MessageService.queryMessagesPage path and compare the rmq.topic.list and rmq.group.list envelopes. Add catalog and handler coverage for default/custom paging, body omission or inclusion, and truncation metadata; done means validation, permissions, filters, and the paged output contract all pass without provider-specific changes.

Written by the indexing model from the issue text.

Assessment

Tech stack
java
Domain
api, backend-api-design
Issue type
Feature
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
68/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.