Felix-Gong opened a new issue, #11468:
URL: https://github.com/apache/rocketmq/issues/11468
### Search before asking
I checked open and closed issues and PRs for `AdminSendMessage`,
`system_properties.keys`, `buildAdminMessage` and `setKeys`. The open work on
this class (#11356 / PR #11357 on message-group queue selection, #11406 on
retry-topic ACL) does not touch the message-key path, and no existing report
covers the repeated keys field.
### What happened?
`AdminSendMessageRequest.system_properties.keys` is a repeated field, and
the data plane keeps every entry: `SendMessageActivity` validates each key and
calls `Message.setKeys(Collection)`, which joins the list. The admin surface
does not. `ProxyAdminGrpcService.buildAdminMessage` reads the same field but
keeps only the first non-empty entry:
```java
for (String key : systemProperties.getKeysList()) {
if (!key.isEmpty()) {
message.setKeys(key);
break;
}
}
```
Send a message through `AdminSendMessage` with `system_properties.keys =
["k1", "k2", "k3"]` and the stored message carries only `k1`. The RPC answers
`OK` with a message id, so nothing tells the caller that two index keys
vanished. Messages keyed this way are then only findable by `k1` in key-based
queries, which is the whole point of sending keys.
The singular `key` field still works (covered by the existing
`adminSendMessageCarriesTagsKeysAndPropertiesTest`); only the repeated
`system_properties.keys` path is lossy.
### Runtime
develop at 57c2dc0, Temurin 11 (the pinned surefire/ByteBuddy stack does not
run on JDK 21). Reproduced with the existing `ProxyAdminGrpcServiceTest` mocks
— no broker needed. On the unpatched service, the new test fails with:
```text
expected:<key1[ key2 key3]> but was:<key1[]>
```
### Expected behavior
Every non-empty entry of `system_properties.keys` ends up on the message,
space-joined like the data plane does. Empty entries are skipped. Precedence
stays as it is today: a non-empty `system_properties.keys` overrides the
singular `key`; an all-empty list leaves the singular key in place.
--
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]