iloveeyjafjalla opened a new issue, #11369: URL: https://github.com/apache/rocketmq/issues/11369
### Before Creating the Bug Report - [x] I found a bug, not just asking a question, which should be created in [GitHub Discussions](https://github.com/apache/rocketmq/discussions). - [x] I have searched the [GitHub Issues](https://github.com/apache/rocketmq/issues) and [GitHub Discussions](https://github.com/apache/rocketmq/discussions) of this repository and believe that this is not a duplicate. - [x] I have confirmed that this bug belongs to the current repository, not other repositories of RocketMQ. ### Runtime platform environment OS: any (proxy module, admin gRPC surface) ### RocketMQ version branch: develop Git commit id: 9ea2ccdc2b41445aee5e177e14e501d606f5a1ed (2026-10-08) ### JDK Version Compiler: Temurin 1.8.0_504 (target 1.8, same as CI) ### Describe the Bug `QueryMessage` accepts the request's pagination fields and then ignores them, while answering `OK`. The proto declares page-style pagination and a cursor: ```proto // ListMessageRequest // Page-style pagination parameters. optional int32 page_num = 8; optional int32 page_size = 9; ... // ListMessageResponse // Cursor to be passed back to fetch the next page. optional string scroll_id = 3; ``` The implementation reads none of them: only `max_message_nums` is honored (defaulting to 32), and the response echoes the request's `scroll_id` back: ```java int maxNums = request.getMaxMessageNums() > 0 ? request.getMaxMessageNums() : DEFAULT_MAX_MESSAGE_NUMS; ... ListMessageResponse.Builder builder = ListMessageResponse.newBuilder().setStatus(ok()); if (request.hasScrollId()) { builder.setScrollId(request.getScrollId()); } ``` Consequences: - a caller that sets only `page_size = 10` receives up to **32** messages (the default cap) instead of its page size; - a caller that asks for `page_num = 2`, or that passes the `scroll_id` from the previous response back, receives the **same** first page again with `OK` — there is no ordering or cursor behind it, so a paging client loops on the same data; - the echoed `scroll_id` claims a continuation exists that the proxy never issues. ### Steps to Reproduce 1. Run a proxy with `grpcAdminServerEnable=true` on a topic with more than one page of messages for a key. 2. Call `QueryMessage{message_key, page_size:1}` — more than one message comes back. 3. Call it again with `page_num:2` (or with the `scroll_id` of the first response) — the same first page comes back with `OK`. ### Expected behavior The fields that can be honored are honored (a `page_size` acts as the result cap), and the ones the open-source broker cannot serve — `page_num` beyond the first page and `scroll_id`, which both need a cursor the broker does not provide — are refused with an explicit status instead of silently returning an unscoped page. `scroll_id` is not echoed back as if a cursor existed. This is the rule the same RPC already applies to its unsupported `search_key` variants (`subscription` / `lite_topic` / `SEARCHKEY_NOT_SET` → `BAD_REQUEST`) and the documented surface rule in `docs/proxy-admin.md` §8. ### Actual behavior `OK` with an unscoped first page; `page_size` ignored; a `scroll_id` that cannot fetch anything echoed back. ### Additional context Fix: cap the result by `page_size` when it is set, refuse `page_num > 1` and any `scroll_id` with `BAD_REQUEST`, and document the boundary in `docs/proxy-admin.md` / `docs/proxy-admin-zh.md` §8. -- 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]
