[Bug] AdminSendMessage keeps only the first system property key, dropping the rest

Open
  • Is something wrong?
#11,468 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

@Felix-Gong is already working on this.

Since Oct 20, 2026.

  • #11469 by @Felix-Gong — open

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
35/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Stale
Tech stack
java
Domain
backend-api-design

Research direction

Start in ProxyAdminGrpcService.buildAdminMessage and compare its handling of AdminSendMessageRequest.system_properties.keys with SendMessageActivity and the existing adminSendMessageCarriesTagsKeysAndPropertiesTest in ProxyAdminGrpcServiceTest. Extend the test to cover multiple non-empty keys, empty entries, and precedence over the singular key, then run that test on the repository's supported JDK. Done means all non-empty repeated keys are space-joined and the existing singular-key behavior remains covered.

Written by the indexing model from the issue text.

Description

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:

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:

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.

Dominant language
Java
Stars
22.7k
Forks
12k
Avg merge
3d 18h
Merged PRs (30d)
17

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/rocketmq

All issues in apache/rocketmq

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.