iloveeyjafjalla opened a new pull request, #11366:
URL: https://github.com/apache/rocketmq/pull/11366
### Which Issue(s) This PR Fixes
- Fixes #11364
### Brief Description
The two lite-topic filters the admin proto documents were silently ignored,
so a lite-scoped query was answered with the
parent topic's data:
- `DescribeGroupAccumulationRequest.lite_topic` ("Restrict the query to a
single lite topic multiplexed onto the topics above")
was never read: the RPC returned `OK` with the whole parent topic's
accumulation and an empty `lite_topic_accumulation`.
- `ListConsumerConnectionRequest.liteTopic` ("Optional lite topic filter,
multiplexed onto the topic above") was never read:
the RPC returned every online client of the group whose group-level
subscription table contains the parent topic, including
clients that never subscribed to the requested lite topic.
Neither variant can be answered truthfully here: the open-source broker
reports lite-topic lag only as a single total
(`GET_LITE_GROUP_INFO` → `totalLagCount`) without the inflight / ready /
deliver-delay split this response is built from, and
per-client lite subscriptions are only known for the clients attached to the
proxy that is asked (the listings are
cluster-visible). The change therefore refuses the variant with
`BAD_REQUEST` and an explanatory message — the rule this
surface documents for itself in §8 "Honest boundaries" and already applies
to `QueryMessage`'s unsupported variants — instead
of presenting the parent scope's numbers as the lite-scoped answer.
`docs/proxy-admin.md` §8 and `docs/proxy-admin-zh.md` §8 gain the
corresponding boundary entry.
### How Did You Test This Change?
New tests in `ProxyAdminGrpcServiceTest`:
- `describeGroupAccumulationRejectsLiteTopicFilterTest`: a request with
`lite_topic` set must be answered with `BAD_REQUEST`
mentioning `lite_topic`, and no broker call may happen. Before the change
the RPC answers `OK` with the parent topic's
accumulation from the stubbed broker data (assertion fails); after the
change it is refused before any broker is asked.
- `listConsumerConnectionRejectsLiteTopicFilterTest`: the same for
`liteTopic`; before the change the stubbed client is
returned with `OK`, after the change the request is refused.
Results on Temurin JDK 8 (same JDK as CI), base `9ea2ccdc2` plus this patch:
- before the fix: both new tests fail with `expected:<BAD_REQUEST> but
was:<OK>` (the accumulation test returns the parent topic's 40-message backlog,
the listing test returns the stubbed client)
- after the fix: `ProxyAdminGrpcServiceTest — Tests run: 62, Failures: 0,
Errors: 0, Skipped: 0`
- `mvn -B -ntp -pl proxy -am package` (checkstyle + spotbugs enabled):
`BUILD SUCCESS`, spotbugs `BugInstance size is 0`
This change was prepared with AI assistance (analysis, patch and test
drafting); the diff and every result above were
reproduced locally by running the module's tests against the base commit and
the patched tree.
--
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]
